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ABSTRACT 


This report Is a technical description of the 7094 
Compatible Time Sharing System in use at Project MAC and the 
M.1.T. Computation Center. It is designed to acquaint a 
system programmer with the techniques of construction which 
were used in this particular time-sharing system. Separate 
chapters discuss the overall supervisor program flow; 
console message Input and output; the scheduling and storage 
algorithms; anda thumbnail sketch fs given of each of the 
subroutines which make up the supervisor program. 


This report was prepared with the ald of the compatible 
time-sharing system and the TYPSET and RUNOFF commands. 


“Work reported herein was supported (in part) by 
Project MAC, an M.1.T. research program sponsored 
by the Advanced. Research Projects Agency, 
Department of Defense, under Office of Naval 
Research Contract Number Nonr-4102(01). 
Reproduction in whole or in part is permitted for 
any purpose of the United States Government." 
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Preface 


The writer Intends these notes to provide a technical 
introduction to the operation of the 709% Compatible Time 
Sharing System for a user. who wishes to participate In 
programming and related development of the time-sharing 
system. in thelr present rough form, the notes attempt to 
fill as quickly as possible a need for tutorial 
documentation of the time-sharing system. 


The becder should have considerable experfence in 
computer programming, Including a knowledge of the machine 
language (FAP) of the 709% computer. He should also be at 
least a casual user of the time-sharing system and. thus 
familiar with the operating characteristics of the system, 
and he should be famillar with the system description 
provided In the CTSS users’ manual (1). However, when 
highly technical aspects of the 709% operation or special 
features of the time-sharing system are discussed, the notes 
will provide enough background materltal for a reader 
famillar with these subjects. 


Nota: In the Interest of getting Into distribution a maximum 
amount of Information In a minimum amount of time, sections 
5,6, and 7 of the Technical Notes consist mostly of tables 
and charts, with a minimum of verbal description. They 
should provide a useful reference source, though they are 
not reget or tutorial purposes. 


nit 
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Compatible LIime-Sharing 
ayvatem: A quifas, M.t.T. Press, Cambridge, 
adie 1963. 
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1. Introduction to the Technical pebects oF Glee. 


In this section we wilt review bavocal Ideas which are 
covered in the CTSS Programmer's Guide, but from the polnt 
of view of a system programmer rather than that of a user of 
the system. We will) diseussyin: turn, the computer on which 
the system operates; the. overall. design principles; the 
place of the disk and drum memories in the system: the 
relation between the user and the supervisor; the types of 
commands; and finally, the modular construction of the 
system supervisor. 


ihe famauber. 


White many of the Ideas Involved tn the time-sharing 
system are to some extent independent of the computer which 


- the system uses, a technical discussion presently requires a 


specific reference to detalis of the particular computer. 
The computer In these notes is the 8M 709% with several 
special features. The most: ‘impertant are; 


1. Core storage Interval. timer clock. This Ineludes = an 
- “alarm clock" which can cause a. program interruption 
similar to a data channel trap... : 

2. Memory protection and relocation registers. These 
permit a section of the. computer memory. and certain 
instructions to be declared “off limits" to a program; 
a trap wit} occur whenever. a eroeran: attempts to tread 
“off os 


3. At: tedit five data channels, connected to the following 
equi pment: 


Channel A: Printer, punch, reader, tapes, and 
. Chronolog clock. 


Channel 8: Tapes... ; 
Channel C: Disk and Drum Storage. 


Channel D: Direct data input and output for special 
experiments. 


Channel E: 7750 Communications Channel (which 
communicetes, with typewrl ter consoles). 


The Project. MAC . Computer has two. additional channels: 
Changed Fs Disk and Drum Storage. 


Se ey ee wee a 5 RR 
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Channel G: HIgh Speed Drum, 


h, Two 32K core storage modules. 


These special features are combined with an extensive 
supervisor program, known as_ the "time-sharing system 
supervisor" to provide a complete time-sharing system. 


Design Principles. 


it will be somewhat easter to understand the general 
Import of the ideas to be presented in these notes If some 
of the principles of design of the time-sharing system 
supervisor oer clearly at this point. 


1. Although subsidiary computers (the IBM 7750) are 
an integral part of the system, as many -functions as 
possible are carrled out by the 7094, This centralization 
of supervisor control ts primartly to simplify the job of a 
person trying to learn how the system operates. 


Zs The system is designed for the maximum possible 
Interaction rate with the user: the 709% accepts = each 
character as it Is typed by each user... It is not necessary 
for the user to communicate on aie line-by-line or 
paragraph-by-paragraph basis with his program, although many 
programs do not attempt to take advantage of the maximum 
interaction rate. 


3. Input and output from user programs are _ provided 
by supervisor subroutines which allow the user to specify by 
name the function he desires without Irrelevant detail and 
bookkeeping on Als part. For example, if he wishes to store 
some iInformation-on the disk he gives the supervisor the 
block of information and a name by which he knows the block; 
he can retrieve [t later by asking for It by name. He need 
never worry about disk track numbers or complicated data 
channel programs. Similarly, the mechanics of communication 
with a typewriter console via telephone lines would deter 
even the most experlenced programmer; but a subroutine cal] 
Is provided which accepts a message and the Information that 
it Is to be typed on a console; the supervisor subroutine 
takes care of the rest of the details. This principle’ is 


carried to the point that the user is required to do all his 


1/@ via supervisor subroutine calls. 


4, The supervisor is designed to be _ context-free. 
That is, although It accepts commands from a user, it has no 
direct interest In what the commands do; It considers a 
command name to be merely the name of a program to be found 
in a directory; when the program has been found it is loaded 
and started just like a program written by the user. 


“— Techn Feal Notes 


Use of Disk and Drum Storasa. 


As mentioned above,. input. ane output are handled = by 
supervisor subroutines for the user. This ‘comment appites 
espectally *té ‘the disk fl te and the magnett<¢ drum memory. A 
special supervisor module, the disk control, handles all. 
input and output for these ‘unfts, The: “disk control module 
has been desfgned so that the user cannot distinguish 
between the disk and drum memortes. There, are four primary 
uses of the disk files: , 


2 User files. These are filles of arcrameion which a 
user wishes to store away for future reference. They 
may consist of programs, data for programs, or any 
other Information the user desires, They are kept on 
the disk Indefinitely and allow a user to retrieve a 
program several weeks after he wrote [t, Thus, the 
disk ‘replaces the decks of cards and reels of magnetic 

- tape: usually — associated with a large computer 
Installation. 


2. Working programs. When @ Program actually cee It 
-sharést- the computer with several other users. Stnce 
not aj} ‘of these users will fit into core memory at 
once, the excess are stored temporarily on the disk or 
drum to be brought tnto. the computer when their turn to 
use the central processor comes up agatn. 


3. Supervisor commands « Whenever a user “types a  super- 
visor command, he implicitly requests ‘execution of a. 
program. in most cree, iit command elo Eran ts kept 


he Scratch Pad memory. ‘Meni: “programs, such as trans-. 
lators, require targe btocks of temporary storage which 
da not fit Into core memory. The disk Is also used to 
fulfill this need, . on 


All filles kept on the disk (and drum) are known to the 
user only by name: the supervisor disk control module keeps 
for each user a Gh ibaa of names and corresponding track 
locations Gh the disk, A simple chaining perenne ts used 
to locate any given file... 


A master file directory, which contains the 
‘dent ittcee ton: of all potential users of the system, starts 
at a fixed place on the disk and contains all = pertinent 
Information about: the user, Including the: locatton of his 
personal file directory. His file directory. lists names and | 
starting locations on the disk of: each of his = personal 
files. Every user of the disk contrel module, Including 
even the supervisor, must appear in the master file 
directory. As will be seen later, the supervisor modules 
are also stored In relocatable binary form as files on. the 
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disk under the user number of a_ spectal BSS loader which 
starts up the system, 


Relation Between User, User Progyam, and Supervisor. 


For every possible user of the system, there jis an 
entry In the Master File Directory of pertinent informatton 
about his identification and use privileges. There is no 
information, however, about the nature of the console he 
might use; this information fs not of Interest to the 
supervisor and only concerns the user (and possibly his 
program). 


When a user logs in to the system, he is assigned a 
user number and thereby becomes subject to the attention of 
the scheduling algorithm. A logged-in user is assigned a 
"state" according to the demands he is placing on the 
system; this "state" will usually change several times while 
he is using the system. Each state has an associated code 
number: 


0. "Dead", This state corresponds to a user without a 
program. He may be in this state because he has just 
logged in and has not yet loaded a program, or because 
his program has just completed execution and returned 
him to the dead state. In all states but this one (and 
sometimes state 3) there exists a "core image" of a 
program for this user, 


l. "Dormant", A user is tn the dormant state when he has 
a program which is potentially runnable, but which’ for 
some reason the user does not want to execute at. the 
moment. His program is probably not being kept in core 
memory but temporarily on the disk file, until he gives 
the word for it to begin execution. A user will be in 
this state if he has just loaded a program but has not 
yet started [t; or if he has just finished program 
execution and returned to the dormant. state, This 
latter possibility differs from the similar situation 
described under "dead" in that the core image of the 
program remains available either for rerunning or _ for 


postmortems., 
2% "Working". A user is in this state whenever his 
program is scheduled for execution. Working users 


actively share the use of the computer, but only one of 
them is actually in execution at any. given’ instant, 
while the others may be in core or stored as core 
Images on the disk just like the dormant users. All of 
those trying to execute are considered to be in the 
working state. 
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3. “Waiting Command", If a-user is in either the Dead or 
Dormant state, anything he types is considered a 
command to the supervisor. When he finishes typing a 
command, the supervisor places him in state 3. to 
Indicate that he shauld:-be actively considered by the 
scheduling algorithm. When his turn comes to use the 
computer, the cokresponding command program is located, 
loaded if necessary, and his state Is then changed to 
"working", Note that a command program is considered 
to be the user's program; once It is loaded it is 
Indistinguishable from one of the user's own programs. 


he. "Input Watt". When a working user program attempts to 


read a line of tnput from the console typewriter, there 
ts a good chance that the user (typist) has not yet 
finished typing the line. In this case, the user is 
assigned state 4, and he Is temporarily ignored by the 
scheduling algorithm until such time as the needed line 
has arrived. Although fn principle a request for input 
from any device could result in the input wait state, 
this state does not apply durtng the reading of a_ file 
of information from the disk. The rate of information 
transfer in this case Is so high that more time would 
be lost switching users than waiting for the first 
user's input to arrive. 


5. "“OQutput Wait". When a user's program attempts to type 
out a serles of messages on the typewriter console, 
messages may be produced at a higher rate than the 
console can type. After a few such messages have been 
absorbed by intermediate buffers, the user is placed In 
state 5 until the messages clear sufficiently to permit 
the program to proceed. The output waft state could 
also apply to any output device requested by the user, 
but considerations similar to those . described under 
input again apply. 


One further noteworthy detail of the present 
implementation makes clear future remarks. The two memory 
banks of the computer will be referred to as "memory A" and 
"memory B".. The supervisor ts tn memory A, and user 
programs are in memory B. It Is not essential that such a 
diviston of equipment take place, but a formalized division 
greatly simplifies the programming within the supervisor. 


A. command program jis nothing more or less than a-. 
complete program previously written by someone, which fs. 
stored in the form of a core Image ready to load and run. A 
number of those command programs are considered "public 
commands" and are stored in the supervisor's disk files. 
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Other, private command programs may be stored in a_ user's 
private file. Examples of public command programs are the 
MAD and FAP translator programs. An Important aspect of the 
way in which the. supervisor handles commands (requests for 
the execution of.a command program) is that the supervisor 
remains aloof, as it were, from the operation of the command 
program, 


Suppose a user types the command MAD with appropriate 
arguments. The supervisor accepts this Input line after 
checking that it is in fact a command, When it Is the user's 
turn to run, the supervisor looks up the command name in a 
command directory which contalns BCD command program names 
and command program starting locations. if the command 
named MAD ts found [n the directory, the file named "MAD 
Tsspc." ts read from the disk Into core B and started at 
the location given in the directory. This command program 
ts now the user's program and runs exactly as If he had 
written and loaded it himself. Note, however, that the 
supervisor itself has no Information about the command or 
what {it does, except Its name and starting location. It is 
In this sense that the supervisor Is context-free. 


There are, in fact, three kinds of commands; we have 
just described the operation of "disk=-loaded" commands, A 
second type of command, also context-free, ts the B-core 
| command. If the user types a B-core transfer 
command and is in a dormant state (that Is, has a B-core 
Image), his core Image Its loaded and the transfer is made to 
a special place in his program (again given in the 
supervisor's command directory). Examples of B-core 
transfer commands are PM and FAPDBG, These functions are 
carrled out by subprograms which are loaded as part of the 
user's program. The third command type Is the A-core 
transfer command, which requests an action Intimately 
connected with the supervisor and fs thus not. strictly 
context-free. Examples of this type are LOG@UT, LOGIN, and 
SAVE. Here no loading Its needed, since the command programs 
are bullt [Into the A-core supervisor. 


Ihe Modular Iime Sharing System. 


The supervisor program has been written in the form of 
modules, for ease in understanding and modification. Each 
module of the supervisor takes charge of a specific. 
function, such as typewriter coordination, disk file tnput 


‘and output, or scheduling of user programs. The modules are 


written in languages which produce binary programs In_ BSS 
relocatable form; thus the modules may communicate with each 
other only through the two standard communication procedures 
of BSS programs, namely the transfer vector and _ program 
common. Thus the number of Interconnections between 
separate parts of the supervisor its minimized and such 
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interconnections can only exist on a formal, advertised 
basis. Most tmportantly, the reader can study = and 
understand the operation of a specific module while he 
still has but a vague [dea of what happens jinsitde other 
modules. Figure 1.1 is a schematic illustration of a tayout 
in core memory of the modules of the supervisor program, and 
the user programs. The diagram shows only a few of the more 
important modules. 


User Area 


Core 
Memory 


Proce e 
on O 
cise [ees 
A ocato oordinato 
ieee 
ALES aw ot e 
a ne apllocations 


|_Machine trap] 


Supervisor 
area 


Figure 1.1 -- Possible core Memory Layout. 


While the system is operating, the modules of the 
supervisor are in the form of a complete program loaded and 
linked together [fn core memory. However, copies of each 
module in BSS form are stored in the disk file. In addition 
to the modules normally used in the system there may be 
newer modules being debugged, or older modules kept as 
backup in case the presently used version suddenly devetops 
an unforeseen bug. The system is started up by placing a 
modiffed BSS loader into core memory and giving this loader 
a special control card which specifies a lfst of modules to 
be loaded and linked together, The steps fnvolved in 
starting the system are as follows: first, a 7094 program 
loads the disk from a tape copy made of the disk following 
the latest previous use of the time-sharing system; then, 
another 709% program loads and starts operating the 7750 
computer, which handles console typewriter input and output. 
Now, a special BSS loader which contains a copy of the disk 
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~ eontrol module ts loaded, fies a: “ened ‘veader or: bane Into 
the 7094, The toader fs apie lt by ae ““gupervi sor name 
card." The BSS toader has a “amber, and. thus has 
- gecess to the disk fltes with theat@vat: bts: ‘disk control 
--modute. The "supervisor. ame card” spectftes the .name of a 
‘disk fille accessibte to the 88S ‘Yeader witch: contains a tist 
‘of names of the disk files tobe loaded. to: fan a supervisor 


program, 


There are two uiapedking aspects_of this procedure for 
loading the time-sharing system supervisor. First, maximum 
use Is made of existing programs, such as the disk control 


- module. Second, If a module being. checked @ut. develops a 
bug, It can be very easily removed from the system (and an 
older, reliable version substituted) with a minimum of fuss. 


and bother, simply by a: reloading of the special BSS loader 
with a supervisor name card which specifies a different list 
of disk filles to be loaded to produce the supervisor. This 
feature Is vital In a system which Is in use while still in 


‘a state of development. 


Epllogue. 
In conclusion,, a picture of “the magni tude of this 


| undertaking, in terms of relative . size of the programs 
‘Involved, may be of tnterest. | The supervisor program 


consists of ahout. 12,000 (decimal). ftnstructtons plus tables. 
This figure compares with 11,000: for the MAD compiler, 
16,000 for the FAP assembler, and some 69,000 instructions 
in the older 1BM Fortran 11 compiler. Thus. In the proper 
perspective, the time-sharing system ‘supervisor Is an 


undertaking comparable to the development of a completely | 


new compiler system. in add¥tion to ‘the FAP and MAD 


translators, command: programs totaling another 6,000 | 


Instructions are necessary. to frame out a “usable” time 
sharing system. 
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introduction. 


In this section we examine the general flow of control 
within the supervisor program and consider when and how it 
obtains control, and what happens when it does. In dofng 
so, we will get a slightly closer, but not detailed view «0° 
several of the important supervisor modules. 


Supervisor Program Elow. 


Suppose a user's program Is operating. The program !5 
located [In core 8B, and has control of the computer; tlie 
supervisor Is located In core A but is not presently in 
operation, There are three events which can cause thie 
control of the computer to transfer to the supervisor, ‘15 
Indicated in figure 2.1. 


First, tf any user at any typewrlter types a character, 
he causes a data channel trap at the 7094, Control passes 
to one of several special supervisor modules’ called 
{tnput-Output Adapters. The appropriate Adapter accepts the 
character, performs any necessary code conversions on it, 
and places [ft Into a common [nput pool buffer along with the 
typIst's "user number", Control then returns to. the 
interrupted program which continues as ff nothing had 
happened. A data channel trap Is a true "fnterruption" as 
it may occur at any point In the user's program. 


A second event which gives control to the supervisor is 
the following: after a period of time known as a ("clock 
burst," and typically of value 0.2 seconds, a clock trap 
occurs, ‘which passes control of the computer to the 


supervisor clock trap processor. At this time the 
supervisor does most of fits "housekeeping" work. The 
typewrlter coordinator processes input and output between 
user programs and typewriter consoles. The supervisor 


examines commands typed by other users and makes notes, 
Finally, the supervisor consults the scheduling algorithm 
module to learn whether or not this user should be permitted 
another "clock burst" of running time. If he !s allowed to 
continue running, his program ts restarted at the point at 
which {it was Interrupted by the clock trap; If not, another 
user Is allowed to run, and a "swap"! may have to take place. 


We have thus far looked at two ways [n which control 
may pass from the user's program to the supervisor. Both of 
these traps, data channel! and clock, have the property that 
they may occur at any point In the user's program. The 
third event which causes control to pass to the supervisor 
however, is completely under the user's control. This event 
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Figure 2.1 -- CTSS supervisor, overall flow. 
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Is the (presumably) intentional protection mode violation; 
the signal that the user Is calling on the supervisor to 
perform some special subroutine function. When such a 
subroutine call occurs, of course, the operation of the 
supervisor depends on exactly which subroutine has been 
requested. !n general, however, If the user's state has not 
changed as a result of the subroutine call, control returns 
to him directly as soon as the subroutine operation has 
finished, unless he used up his "clock burst" during the 
operation of the subroutine. If the user's state has 
changed as ‘a result of a subroutine call, for example, a 
call which requests a change from working to dormant status, 
control passes Instead to that portion of the supervisor 
concerned with locating and running another user program, 


Data Channel and Clock [raps. 


For the interpretation of the flow diagram in figure 
2.1, the operation of the data channel and clock traps must 
be understood. These two traps may be elther enabled or 
disabled. In the supervisor, they are almost always enabled 
and disabled together. If a trap Js enabled, the program In 
operation, whether user or supervisor, may be [Interrupted at 
any time; the program has no control over’ interruptions 
except to disable the traps. On the other hand If the traps 
are disabled, when a trapping condition occurs the program 
Is not Interrupted; Instead the trap is remembered unt!’ 
such time as the traps are re-enabled (restored). The 
ability to'disable traps, yet remember them, is necessary in 
order that the supervisor may handle all traps In an orderly 
manner. 


The dotted boundary in figure 2.1 is the disable-enable 
boundary; all programs Inside the boundary run with data 
channel and clock traps disabled, those modules outside the 
boundary run with data channel and clock traps enabled. 
Thus a data channel trap gannot occur while [n_ the 
scheduling module but may occur while In the disk control 
module, 


When a clock or data channel trap occurs, further clock 
and data channel traps are Immediately disabled, The 
supervisor continues to run with traps dltsabled until tt 
elther returns to the Interrupted program or It goes to. the 
sway (main control) section. 


Note that care must be taken to insure that an enabled 
supervisor subprogram Is never entered following a trap from 
the very same program, To make sure that this does not 
happen, the clock trap processor never goes to the swap 
section if a trap has come from core A. Instead, If a swap 
1s needed, only a switch [s set, and return Is made directly 
to the point of Interruption of the core-A subroutine. When 
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the subroutine has finished, It returns to the user. program 
via the common user return RSTCPU, Sitnce the user may have 
run out of time durlng the subroutine operation, RSTCPU 
checks the swap switch and If a swap Is needed, performs the 
transfer to the swap section whicn the clock trap processor 
was afraid to do before. 


After the brief consideration of a general picture of 
the supervisor operation, it may be useful here to lIst all 
of the modules with a brief sketch of their diverse 
purposes. The block diagram, figure 2.2, shows the general 
relationships between the various modules, although flow of 
control between modules is not unambiguously Indicated, 


Each module is a subroutine, or group of related 
subroutines, filed by a six-character primary name and a 
secondary name corresponding to the language In which the 
module is written. The first four characters of the primary 
name are mnemonically related to the function of the module 
and the last two characters are a number indicating the 
version of the module. Some modules, because of thelr size, 
are split between two or more filles. Such a.s.split may or 
may not Imply separateness of functions of the parts of the 
module. The names of the modules and their functions In the 
versfton "1A1" system are: 


Primary File 


Name Function 

MAIN Initialize time-sharing supervisor. 
CLOC Clock trap processor. 
CTRL Matin Control Section. 
STOR Storage algortthm, 

SCDA 

SCOB 

scoc Scheduling algortthm.* 
SCDD 

SCDE 

SCDF 

SCOG 

TC@R Typewriter coordinator. 


PMTA Protection mode violation processor. 


CTSS Technical Notes PAGE 13 


RTRN Common exit routines to return to 
trapped programs. 

SAVR Save and restore user machine conditions. 

UTRP Process STR, floating point, and data 
channel traps for user programs. 

RFLX Processes user input lines. 

CYMC Miscellaneous subroutines. 

C@MD Command directory (no instructions). 

CONV BCD conversion routines. 

@NLN Do on-lfne !/% for supervisor. 

EDBG Post mortem and trace routines for 
debugging the supervisor. 

LOGA 

LOGB LOGIN, LOG@UT commands.* 

L@GC 

SAVC Start, save, restor, resume commands. 

gCTC OCTLK, PCTPAT, and OCTTRA commands. 

DSKI Disk control, 

ADP I 7750 t/O adapter, 

AP75 7750 Write subroutines. 

TST@ Assign 7750 storage.* 

CHNE Channel E hardware subroutines. 

H1IGH High speed ltIne adapter. 

UNIT : Asstgn and look up logical user numbers. 

DCER Handles channel E errors. 

PLOTS 

or Channel D 1/0 adapter. 
KLUD 
* Indicates a module written In the MAD language. The 


other modules are written In FAP, 


NOTE: More detall about the entry points of each module is 
contained In Chapter 7. 
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Figure 2.2 -- Block diagram of supervisor showing important Inter-module links. 
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3. Input and Output 
introduction. 

In thls section we will study the communication between 
the user and his program in the tIme-sharing system. We 


will discuss specifically how a typewriter communicates with 
the system, although the ftdeas can easily be extended to 
more exotic forms of input and output devices 


To allow a continuous flow of input or output between 
the typewriter and the user's program, which may not be in 
core memory at all times, the supervisor provides buffers 
for the data being transmitted. Input messages are buffered 
in core A, within the supervisor, while output messages are 
buffered in the 7750 computer. 


Ihe General Logic of Inout Elow. 


Figure 3.1 Is a flow diagram of the handling of | input 
from a typewriter by the time-sharing system. We may begin 
with a user typing a character on his’ typewriter. This 
character travels via telephone lines to the 7750 computer. 
The 7750 accepts the character, and turns on the 7909 data 
channel. The 7909 data channel places the input character 
in a buffer in the 7094 memory and causes a 7094 data 
channel trap to the appropriate 7094 input adapter. The 
input adapter program moves the character into a character 
pool buffer, tn the form of a word containing the character 
in the address and logical user number in the = decrement. 
This format, used for all character-orlented devices, is 
known as "Interface I", The character pool buffer is 
capable of holding about 600 such characters (for 30 users). 
The 709% then returns to whatever business Itt was about when 
the trap occured, 


The characters in the character pool buffer are thus 
left for a later section of the supervisor to examine = and 
eventually route to the proper destination. It ts 
fundamental that the 7094 computer responds to input 
character by character so that if a user program desires, it 
can communicate back and forth on a character by character 
basis with the user. 


Further processing of input resumes when a clock trap 
occurs, giving the supervisor program intentional, compiete 
control of the computer. At this time the Input characters 
are processed in two stages. The first stage, handled by 
the typewriter coordinator module, collects characters into 
messages, Each user has a separate secondary read buffer, 
and all characters which he types are moved to his secondary 
read buffer by the typewriter coordinator. No further 


709% 


Data 
Channel E 


processor (after 
TCOORD done) 


| 

Clock trap | Clock trap 
| 
| 


Move completed 
lines to 
SS e> appropriate 


7909 data 
channel 


1 
jat 
1command 

7750 ilevel 
ILINES . 
I I \ 
type- type-| etc. return to return to continue * 
writer|\ writer Interrupted | clock trap clock trap \ 
processor processing ‘ 


| program | 


char.,,user no, 


RDTELY | tTcoorD 
Input Adapter | Typewriter 
Coordinator A call to subroutine RDFLX 


obtains a line from the 
user lines buffer if there 
is a line for that user. 
If not, STATUS(CUSER) is 
changed to Input Wait. 


Figure 3.1 -- Simplified tnput Flow. 
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action is taken unless one of the characters typed by the 
user Is found to be a "break" character such as a carriage 
return or other special character designated by his’ program 
as a break character. When a break character Is found among 
the input characters his message is considered to be 
complete, and no more characters are placed in his secondary 
read buffer. If more characters rematn in the character 
pool buffer for this user, they are left there until his 
secondary read buffer is free. <A program switch is set to 
indicate that thls user has completed typing a message, The 
typewriter coordinator attempts to thus dispose of all. of 
the characters in the character pool buffer by distributing 
them to user secondary read buffers. 


When the typewriter coordinator is finished moving 
characters into the secondary read buffers, the second stage 
of input processing begins. At this stage, handled by the 
clock trap processor module, completed messages are 
delivered to thelr final rectpients' "maflboxes",. If the 
user Is at command level (dead or dormant) the message is a 
command and ts placed in the user's command buffer. I!f the 
user [s not at command level, the message is for his 
program, and so it is moved to the “user lines" buffer. 
There the message remains until his program calls upon. the 
supervisor subprogram RDFLX for final delivery. 


Note. that the second stage, which removes the message 
from the secondary read buffer, is not strictly necessary; 
the user's secondary read buffer could be considered as his 
mailbox. The second stage could consist only of noting 
completed messages from users at command level. A_ floating 
buffer scheme to do this simplification could easily be 
Implemented, 


An tmportant reason for the modular construction of the 
system supervisor is well illustrated by the input scheme. 
There may be any number of Input adapter modules 
communicating with character-orltented devices. Each of 
these modules, upon obtaining control from a data channel 
trap caused by fits hardware Input device, can place 
characters [In the character pool buffer in the standard 
Interface | format. The processing done by the typewriter 
coordinator [ts completely independent of the source of the 
character in the character pool buffer. The adapters can be 
considered as "matching devices" between the specialized 
hardware requirements of different input devices and the. 
standardized characteristics of the input interface of the 
typewriter coordinator. 


The General Logic of Output Elow. 


Having looked briefly at the input side of 
communication between user and user program, we will 
postpone detailed discussion of the input modules until we 


Inca way quite e@lnltar. to . 
- produce cutout at avery bleh. 


- program does: not. return. to. workd: 


figure. 3.2, 2 Slow. dissrem of output. 


for 29 words; since. three 12-bit. characters. 
word, there Is room for-# Mee of BS, , SATSRtOLS plus a 
carriage return, : 


7750: computer. ‘The 
> wate seetus. when 


the beginning, moving the peel ot Rie 
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have surveyed. the related on eaut 3 a spatpekl Is handled 


Psd come: ‘necessary 
differences. « The major. OP avo as program can 
tae 


a 
a: SYREN can 


too. much 
processor 


“Thus: one can. make sure- “gating, ‘vam: that the system 
keeps up with the typists by. mak ng the. character pool 
buffer large enough to: aqcent,. the . xImum number. of 
characters that al} the typists. ‘could produce In, say, two 
seconds. Then, tf..the typewrlter ..cogrdinator attempts to 
empty the character pool buffer.at. least. once per. second, 


only very rarely will the buf tar. cover tlw: ang, the typists 
told to daatat. eee ner Ts a 


bn: contrast,: ‘the ‘cutout Seni fous: ‘of the ‘guberv leer: must 


ad 


constantly expect to be. overburdened with output lines 


he. typewriters. 


The: supervisor: handles. the: brat om yer ly by refusing 
to accept output from a: prog uples }s room for the 
data In. the outpuc: cutferce rs buffers. are full, the 


user's program is placed tn “output. walt™ status, The user 
i a woe, ‘buffer space 
is. avaltabte for: the. program's: output. 


With: these: gonsideretions In. minds.” we:can now look at 
t. - OF, essing. Output 
ori gtnates when: the’ user's program calls for the supervisor 
sub-program oWRFLX or WRELXA. The user's. Message is 
converted to I2-bit form If ft Is. not a raeey Tn that form 
(that. ts, if the. user. is in tha...normal,...6-bit mode) and 
moved. Inte the primery write buffer. Is buffer. has room 
_are stored In a 


- Subroutine WRFELX now calls: the output adapter. module at 
the entry poltnt. WREELY. to write the. sheers CON O1te on the 
‘ousput lapter. pecform an = error 
return, however,. to: indicate. thet. “the? a350 ‘dogs. not have — 
room for the massage. If ‘this is As. the ase, WRELX itself 
performs: an error return which. places - ‘the . user. tn output 
Space becomes. .evalleble, the 7750 will 
send a completion signal back te.-the ..7094,... and. this user 
will come back .to working status. ‘As: soon as the user 
begins executing. agatn, ‘subers x sterts .over from — 
the “primary write | 
buffer: (since the buffer may have been used be: someone else 
white the first user was in output walths i . 
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WRFLX 
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storage space 
avallable? 


return) 


7909 Channel £ 
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Figure 3.2 -- Output flow. (TCOORD and WRTELY) 


Assuming, however, that the 7750 has room for’ the 
message, the output adapter encodes the message and delivers 
it to the 7750. A detailed description of the output 
adapter, and of the criterion used to determine whether or 
not the 7750 has "room" for a message is the subject of the 
next section. 
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WRFLX also does some processing of the output line. It 
locates the last non-blank character in the lfne and Inserts 
a carrlage return character after it, while it deletes’ the 
trailing blanks. For those applications where this 
processing is not desired, an alternate entry, WRFLXA is 
provided which puts out the line exactly as given. 


Stnce calls to WRFLX and WRFLXA always must specify an 
integral number of words, they also always specify a 
multiple of 3 or 6 characters, depending on the status of 


FULSW. In those cases where a different number of 
characters is desired, the null character, 57 (octal) may be 
inserted to fill out the last word in the block. The 


typewrlter coordinator will ignore null characters found in 
the secondary write buffer. 


Note that the only communication between the 
input-output adapter (the two functions are really handled 
by a single module) and the rest of the supervisor is via 
the primary read buffer CIinterface 1) and the 
subroutine-type call to the output adapter. The resulting 
independence makes it very easy to remove one 1/0 adapter 
program and insert another for a different class of 
input-output devices. 


An 1/0 Adapter Module. 


We are now familiar enough with the general logic of 
input and output to study {In detail the modules’ which 
perform it. We start with. an 1/0 adapter module, but 
remember that this is only a description of a i 
adapter module and that any other. program with = similar 
characterlstics with respect to the primary [Input and output 
buffers can, and occasionally does, replace the particular 
one we are studying. 


The 1/0 adapter module is of course split into two 
quite Independent parts, one handling input and the other 
output. tet us consider the output section first, as 
illustrated In figure 3.2. The output adapter performs the 
necessary code conversion for the user's particular device 
(teletype, 1050, flexowriter, etc.) and places the data _ in 
the proper format. for the 7750, one character per word, with 
the user's telephone line number [In the decrement. The 
supervisor module UNIT maintains a table of correspondence 
between actual user, as identified by telephone line 
numbers, and internal logical user numbers. Each user, as 
he dials Into the system, is assigned a logical user number 
for easy [tdentification. The adapter must then establish 
whether or not there Is room for the message in the 7750 
buffer area. A separate module, TST@, keeps track of how 
much space is avallable in the 7750, and this module also 
decides the policy of who should be allowed how much = space 
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there. There ts room for 10,000 characters in the 7750 
buffer, and the amount which any user inay have is known as 
hts allotment, AL@T. If N characters are actually in use at 
the time a user asks for output space, his allotment is’ 
calculated as 


AL@T = (10000 - N)/& 


if the total number of his characters in the 7750 will not 
exceed AL@T, he [s allowed to perform his. output. If he 
will exceed AL@T, an error return is given to indicate that 
he should go into output wait. 


Consider now the input adapter module, figure 3.3. Via 
this case, control comes to the input half of the module via 
a data channel trap; there is at least one character in the 
adapter's input buffer. The input adapter picks up the 
character, converts It from the 7750 format to Interface | 
format for the character pool buffer and replaces the user 
telephone line number with his internal logical user: number, 
{t then checks to see if this character is really a 
completion signal from the 7750 saying that a 31 character 
buffer has been typed out on this user's typewriter. If it 
is a completion signal, the adapter calls TST® (at entry 
point TGIVE) to tell it to release a block of 31 characters 
assigned to this user. All other characters are placed into 
the character pool buffer for later processing by calling 
entry point T@P@OL in the typewriter coordinator. The input 
adapter restarts the 7909 data channel program, and = returi:, 
via the common exit module to the program that was 
interrupted by the data channel trap. 


Ihe Ivpewriter Coordinator Module. 


Figure 3.4 is a flow diagram of the typewriter 
coordinator program, As _ indicated, the coordinator only 
handles input processing. Actually, WRFLX and WRFLXA, 
described previously, are written as part of the typewriter 
coordinator module. 


The typewriter coordinator is called as a_ subroutine 
once every time a clock trap occurs, by the clock trap 
processor. Its.purpose, you may recall, is to collect 
characters from the character pool buffer into messages’ in 
Individual secondary read buffers. The coordinator begins 
by examining the characters in the character pool buffer at 
one time. Let us follow the path of processing of a_ single 
character. First, the character is checked to see If it Is 
one of the characters In the break character list. If [ft ts 
one of the three special "quit-class" characters, (quit, 
interrupt, or data~=phone hang-up) this character by itself 
Is considered to be a complete message to the supervisor, 
and the ILINES table is set to indicate that there is a 
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Channel E data 
channel trap 
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this character 
In fnput pool, 


Can user be allow- 
ed to produce more 
output? 


yes 
QPOO Reset 
OUTPSW(USER) 


Restart 7909 
Data channel 


Return to Interrupted 
program via common 
exit. 


Figure 3.3 -- Input Adapter Flow Diagram. 
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walting message from this user. To alert the supervisor 
that this Is a special message, the preflx of ILINESCUSER) 
is set to MZE and the quit-class character is placed in’ the 
address of ILINESC(CUSER). If the character Is not a break 
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Figure 3.4 -- Flow dlagram of Typewrlter Coordinator. 


character it will have to be moved into the user's secondary 
read buffer, so the program then checks to see if there is 
any room left in the secondary read buffer. If the buffer 
Is full, the varlable ILINESCUSER) will contain some 
non-zero buffer address; this ts an Indtecation to the 
coordinator program not to attempt to use the secondary read 
buffer. Instead, this character fs put back [Into the 
character pool! buffer. 


Assuming that all these tests are passed, the program 
then checks the variable FULSW(USER) to determine whether or 
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not the user's program is using a full (12-bit BCD) mode. 
If the user is using the ordinary G=-bit mode, the 12-bit 
character coming from the typewriter will have to. be 
translated. This translation includes two’ Important 
features. First, if the character is elfther the "delete 
line" or "delete preceding character," the line, or Jlast 
character, tn the user's secondary read buffer is discarded. 
Secondly, on all other characters a mapping is_ performed, 
when possible, from the 12-bit character to one of the 
allowed 6-bIit BCD characters. For example, a small letter 
"a" and a capital letter "A" can both be mapped Into the BCL) 
letter "A" with octal code 21; however, certain. special 
characters such as the semicolon have no possible mapping 
Into 6-bit codes. if these non-mappable characters are 
encountered, they are discarded at this point. 


Having performed a . 12-to-6 bit conversion when 
necessary, all. characters other than quiteclass break 
characters are stored in the user's secondary read buffer, 
packed either 3 or 6 characters per word, depending on 
whether the user is using 12-bit or 6-bit mode. The final 
check is to see either if the character its an ordinary break 
(end-of-message) character or {ff it filled up the secondary 
read buffer. If either case is true, the variable 
ILINESCUSER) Is set to contain "PZE FIRST,,n" where FIRST is 
the address of the secondary read buffer, and "n" ts the 
number of words In the buffer, This its the tndfication to 
oe supervisor that this user has a complete, waiting i[nput 
line, 


This entire processing operation Is repeated once _ for 
each character found in the character pool buffer. We have 
not discussed here the inter-console  conmunication 
facilities provided by the AD@PT feature of the typewriter 
coordinator. 


Typical buffer sizes used by the typewriter coordinator 
are: 


Primary read (Character Pool) buffer: 600 characters 
(for 30 users). 

Secondary read buffer; 2 per users 14 words. 

Primary write buffer; 1 Only: 29 words (1 line). 


The typewriter coordinator consists of about 500 
instructlons and about 2000 words of buffer space. 


-cTss pacha lent mares ae PAGE 25 


Other 1/0 Devices: Interface iL. 


So. far, the discussion. has bean restricted to 
character-orlented tnput/output devices, Including § the 
typewriter. All such devices have worked through the 
character interface of the time-sharing system, known as 
interface. |... Any .character-type . device can easily be 
attached to the system by providing, an.J/O0 adapter program 
which converts the raw hardware..interface Into the standard 
format of Interface 1, which consists of one .character/word 
in the character pool buffer. 


There Is also another. broad class of devices, such as 
magnetic tape, which work In terms of words, and blocks of 
words. A second iInterface.is provided for these devices. 
The details of Interface |). can be found In M.I.T. 
Computation Center memorandum CC-226. . For any input or 
output device for:. which interface |i appears to. be 
appropriate, an.1/0 adapt Ye may be written to perform 
the function of matching. the hardware characteristics to 
Interface Hi. 
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4. The Scheduling Algorithm and the Storage Algorithm 


introduction. 
in this. section we eitanitne the coereston of two 
important modules’ of: the ‘time-shering © supervisor: the 


module which declde@s who: should: run next ahd for> how long, 
and the module which allocates. the user memory’ area among 
various user programs, These two funct lone) scheduling and 
allocation, are in fact closely related, and have been 
separated in the ‘supervisor’ because the particular 
algorithms used ‘permit the seperate cons iderat ion of the two 
Problems. A more complex al gorithar might consider: both of 
these functions bins rapeouaty, end therefore ‘encompass. both 

. “tHE Boten say Nttng, has crept into 
alth ries nomi netly handled by a 
Separate modul#, © The prope gement’ of. these © Funct ions 
‘Ts still open to’ donate, end the qwedutes deseribed here may 
not represent the best possible organization, © ~ 


| ns Algo1 


All schedul Ing policy is contained In the scheduling 
module; In fact no mechanics of the time=shar ing system are 
performed by this module, The scheduling module is for the 
rest of the supervisor a sage who Is occasionally asked for 
an opinion, but net asked to do anything: else. Since 
mechanics are absent, the schedul Ing module Is well sulted 
to the MAD language, tn which It Is written.  Stnce [ft ts 
hardly necessary to write an Involved description of a 
well-organized “AD program, only the policy Involved will be 
stated, A reader tnterested in exploring how the policy is 
carried out can easily understand the program itself. The 
explanatory comnents at the beginning of the program serve 
to provide sufficient documentation. 


| | | 

The particular schedul Ing policy described here Is ‘not 
the only such policy, and may not be the best policy, 
particularly In the choice of the parameters given in the 


program listing. However, It Is a typical policy, and the 
parameters given are typical parameters. If one concludes 


-. that a different parameter, or a completely different 


policy, will produce. better results, then a different 
-version of the scheduling algorithm may be easily inserted 
into the system Instead, Here, then, are the Important 
aspects of this algorithm. Figure 4.1 is a flow diagram of 
the scheduling algorithm which may be easler to follow. than 
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the program Itself on the first reading of the policy rules. 
These rules apply to system version l1A3. 


1. 


3. 


4k, 


De 


6. 


7. 


8. 


All users in state 2 or 3, "working" or "waiting 
command," are kept in a set of queues, which may be 
considered to be one long queue of users to run, in 
order. 


The queues may be re-ordered at the end of each clock 
period or more frequently, depending on events 
occurring during that clock perfiod. A clock perlod is 
a short perfod of time, typically 200 ms., during which 
some user program runs uninterrupted except for data 
channel traps. 


Each queue has an Integer valued priority level. In 
general, all the users tn the queue with level "j" are 
run before any users in the queue with level "“j+l", 

There are MAXLVL4+1 levels, numbered from 0. 
(Typically, there may be 9 levels.) 


A "quantum" Is the shortest period of time the 
algorithm ever attempts to run auser. A user may” run 
more than one quantum, depending on his level. A_ user 
at level "j" is normally allowed to run 2.P.j quanta, 
although he may be preempted by the aoeiee) of a euser 
with higher priority. 


A user at level "j" Is moved to level "j+l" after he 
has run 2.P.j quarts at level "j". Usually, he then 


stops running In favor of other users at level "j",. 


A user at level "j" fis moved to level "j-1"" after he 
has waited "QNTWAT" 60ths seconds without running at 
all. Typically, this walting time may be 60 seconds, 


A user starts at a level depending on his’ program 
length such that the time required to load his program 
is a fixed proportion of the running time permitted at 
that level. This proportion fixes roughly the maximum 
efficiency of the system. (The efficiency may be 
lower, because of pre-emption. See 8, below, ) The 
"level of entry" function can easily be changed to 
reflect a different policy. 

A user at level "j"' may be pre-empted at the end of the 
next clock burst by a user entering the queues with a 
higher priority. The pre-emption will take place If 
the user now running has run longer than would the 
pre-emptor, 
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figure 4,l--Flow diagram of Scheduling Algorithm, (SCHEDL.) 
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Fiow diagram of Scheduling Algorithm (cont, ) 


decide 


EVENT 5 pic F 
restoring of new, 
user. done, ..- New.. 
user to begin 
running 


EVENT 6 
user changed 
length 

; [Compute LEVEL but don't change 
‘queues. Allow longer running 
time if new CEVEb: fs of lower 


return 


Is head of queues user| 
pol eFarent, £ For. Surrenti: 
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(When the SWAP switch ‘ts’ tot non-zero, the supervisor will 
call EVENT's 3, 4, and 5 In succession as soon as it can. 
NEWUSR will be the next user to run. 


flgure 4.1--Flow dlagram of Scheduling Algor!thm. (SCHEDL.) 
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9. . When a user leaves states 2 or 3°he Is removed from the 

- -queues, When he returns to state 2 or 3 he Is assigned 
a new priority level; his previous, running time Is not 
taken [nto consideration, © “Thesthe atgorithm “concerns 
Itself ‘primarily with ne “times” within 
Interactions. A program call’ ng fora new “eommand Is 
not considered a new inter aeey one” but 1ts- Tevel may be 
changed If the new conmand is longer. 


10. If a user returns to state 2 or 3 he Is placed at the 
aoe of the queue at his priority evel based on program 
ength. 


dhe Background System. 


it will be seen from thi: prcatem’ ‘coding that. one user, 
user number zero, ‘may be accorded special treatment at 
 vartous  potnts: in the algorithm: -User zero: wepresents. the 
background batch-processing system which is maintained = by > 
the supervisor both for compatibility with older systems and 
to provide a guaranteed backlog: ‘of-work for the computer in 
case no regular ("foreground") users should need service for 
a time. The following addittonal policy rules describe the 
position of the background system with respect to the other 
users: 


11. The bkckerouna system Is ‘eVotiya: at the ar of the queue 

of users to-be run. if the queue should become empty, 

' the background system will then run until some other 
user enters the queue. 


12. The background’ operator” “fhiy. “force ‘the ‘pacegcound. 

system to be run by depressing. certain keys on his 

console. The background system will be brought in at 

the next clock trap, and run exclusively until the 

operator signals that normal, time-shared operation 
should cont Inue. Se dt oa 


13. {tt Is possible to guarantee the background system a 
certain percentage of the facility of the computer, by 
setting the variable "PB" to the desired percentage in 
the Inittalization of the algorithm. When "PB" Is 
non-zero, the background system will pre-empt whenever 

it falls behind Its guaranteed percentage. 


Policy on Charges 

The above enumeration of policy rules does not describe 
all of the coding In the scheduling aigorithm: module. As 
ment. toned In the Introduction, a certain amount of 


time-accounting policy is maintained in this module. This 
series ts handled by the coding following "events" 3, 4, and 
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5. (See program listing for definition of an "event.") A 
brief description of this charging policy can be stated in 
the following five rules: 


I Each user pays for central processor time used, 


25 A user may pay for the time [It takes to load him and 
dump him depending on. whom he _ follows or _ precedes. 
Note that with the present storage algorithm, loading 
and dumptng of a user are pot overlapped with 
computation. 


2a The background system is specially privileged; It never 
pays for loading or dumping Itself. 


4, With the exception of background, all users pay for 
thelr own load time. The previous user pays’ for 
background loading time. : 


5. A user pays for his dump unless he Is being pre-empted 
by a higher-priority user. In the latter case, the 
higher priority user pays for the dump. The next’ user 
always pays for a background dump. 


The storage allocation algorithm presently used by the 
time-sharing supervisor has as Its main virtue sImplicity. 
There is no question that a more sophisticated procedure can 
be devised, and wil] be when time permits. However, even 
the present simple allocation algorithm Illustrates some of 
the f[mportant features which must be possessed by. any 
storage algorithm. 


The simplicity of the storage allocation algorithm 
results from two basic features: dumping and loading of user 
programs are not overlapped with computation, and relocation 
of user programs {ts not attempted, Thus all users. are 
loaded starting at absolute location zero, 


The simplest possible storage algorithm would operate 
as follows: when a user must be dumped on to the drum, his 
entire program is dumped; assuming only one user in’ memory 
at a time, all of memory is now avallable for the next 
program, when necessary. The current. storage algorithm 
attempts to Improve this performance by dumping only enough 
of a user to fit In the next user; the earlier user Is 
therefore split Into two parts, the one part on the drum 
memory, and the other part fn core memory, where Its 
Integrity is Insured by the memory protection feature. Thus 
if the first user should be allowed to return to core memory 
his next loading can be done more quickly than in the case 
where he was completely dumped from core memory. 
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Since a third user, following : ‘the ‘second,:. may be larger | 
than the second, Ht ‘may be wesenenyy = 7. everer time: to dump 
more of the first user. 


To titustrate the ‘splitting, ‘onstder thgures 4, 2-4.6, 

In which several successive states of the user memory area 
are shown, tin & 62, user A’ Fs occupying: most: of. core memory, 
‘and fs about to be dumped In favor ‘of user 8.< Following the 
dump, core memory - appears in fig. 3, with part of user A 
In core, part on the drum. Now, user ¢ ‘Is: to -be brought 
Into memory, so user 8 Is splft in the séme-:fashion, as 
shown in figure 4.4. If the next user, -D, requires a. larger 
“space, as Indtcated: tn ae a ‘webg. Co must be. completely 
dumped, the dump of 8 ‘must be: flashed, erid the -dump of A 

continued a little farther, The result ts shown in 4.5. If 
now, following user-D, user ’A Is to run agete,; the “dump of 
user D will have to ‘be complete tbut-onty the part’ of A which 
- was dumped will have to be restored; thus saving. “some time. 
: The result Is shown in 4. 6. 


in this exampte, : ‘only two users; Nand, B, were split 
between: ‘memory and the ‘drum at one thee, Ae: many as 16 
users may be split ‘between core and the .-drunm. AT dumps 
onto the drum are made In blocks of 2048 words. 


Although In the [blustrat ton oaly..a:..emall -arount of 
time was saved ultimately by not. fumelos all of A at first, 
Inia different sttuat kon the ‘tech eyo much more 

effective, Consider for: ‘example, the Je vabeantlon ‘when conly 
two or three conséte sare; each Mitr gael “programs, are 
using the system, ‘with background > apclarge vshare of. 
the time. Stncd buck gradad ts :#1 pregram, most of 
> It retatnas -in core at ‘ati tindss ary emugh “es dumped to. 
‘make room for the smaller foregraund users when “they need — 
time. ‘In this case, time saving can be: Aarge.. . 


When a user is dumped — from: gore: anamor yy” a file ts 
created on the drum memory. This file Includes two- 


- sections: : 
1, The User machine conditions: statue table, and the 
. User disk: status -table™ -tknctudiag - sehe current 
section: of habe user acs ‘dtrectery) 
2. The user! s core image. cas 


'. The second section ‘fs not weltten ue’ a user soins. to. the 


-o “dead™ state, The file created Is of: temporary mede, and 


named "000021 UDUMP.""-for user 23, ete. This. file ts 
- considered one of ‘the supervisor's “personal files. ‘and does 
not appear in the user's file directory. ae ok 
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In figures 4.8, 4.9 and 4.10, are illustrated the three 
subroutines of the storage algorithm, DUMP, UNDUMP, = and 
FREEUP. DUMP and UNDUMP are _ subroutines called by the 
supervisor to perform the functions Indicated by their name. 
The following notes may help in interpretation of these flow 
diagrams. 


ky |f DUMP Is called to dump a working status user, 
it actually only dumps his machine and disc status 
tables and leaves the core memory dump to. the 
routine which tries to make room for the next 
user, This ts done because at the. time the order 
is given to dump a user [t is not known how = much 
of him will have to go. 


2% UNDUMP calls on subroutine FREEUP to dump out 
enough space for the new user to fit Into core. 
Only then can {it restore the new user core’ Image 
and his status tables, 


3. Subroutine FREEUP is called with one parameter 
("NWORDS"), the number of words of core memory 
needed for the next user, 
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‘User area 
of 
Core Memory 


remaining {I 
pert of 


4,4 4,5 4.6 
figures 4.2-4,6--The Onion Skin Storage Algorithm. 
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‘% 
all SCHEDL 
Event 3) 


call SCHEDL. 


Return 


figure &4,8--Flow diagram of subroutine UNDUMP, 
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 PREEUP_ 


Figure 4,9 -- Flow diagram of subroutine FREEUP, 
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Appendix LA 


States of a User 


Se 


Jinput watt | waiting command 


Figure 4,10 


Addittonal transittons not shown: 


1, Quit signal - any state to "dormant" 
23 Forced LOGOUT - any state to "walting command" 


Description of states: 


0 dead - not walting to run and no core image; 

command level. 
1 dormant - not walting to run but has core Image; 
command level, 
working - walting In queves to run or running. 
walting command - wafting in queues for first run 
of a command. 
input walt - program waiting for input from consale. 
output wait ~- typewriter output buffers filled. 


Vs WP 


All input from the console is Interpreted as commands when a 
user is dead or dormant. He is sald to be at command level 
when In either of these two states. 
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Description of Transittons . 


_ the. user typed: In a defined 
command and ts placed Tn. the queues to walt his turn to run. 


ommend to morking = the. user begins to run the 
or the these time, From now on. the command program 
re created exactly Vike a user program. aa 


working to Inout walt - the user's: program needs input from 
in coreels and the user-has: was, yet typed tn an. ~Tnput line. 
RDFLX 


os - the user. “typed in an Input line. 
ceruinered with a eral character, | 


tout walt the-user's program. ef generated 
enough sutpet: ‘to Fin ‘the. output buffers. (WAFLX) : 


 Qutput walt to working - - the output buffers are empty. 


worklig_to-waltlig-cammand the user's program Issued a 
command. (CHNC@M or NEXCPM) . | 


working to dormant - the user's program finished its 
computation but the core image is stil} useful. (DBRMNT) 


d- the user typed In a .defined 
command Shier may: ‘Operate: 00 his core. mage. or. may destroy 
it and start fresh. 


working to dead - the user's program... finished its 
computation and the core” Image is to be destroyed (DEAD). 


dormant to working - supervisor: is. “restarting the user's 
program without: a. console. Interaction... Piwinbe 


SCDA 


DRUADADDADDADDWDDDDWDXTDADDDTDDADWDWDDDADDDMDBDDWDRWDWDVNDDD 
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Reteaneneee Tie rey scite : 
T. NAST ANGE BAD Re * 


DET ines: Priv 
4, DET ERAN USERS: FOR 


ENDING with Tete ARE 


SCHED. HAS SOLE RESPONS RETLIT 
THE FOLLOWING COMMOM ARRAYS: 


Stes ; usta) nay ae OF, EAC H. 
WHERE STATUS J: ae 
0 DEAD - NOT Natt velo 


LOADED, WITH THE EXCEPTION OF * 


+ KEEPS TRACK OF THE ae ee H USER 


oe oe USERS, *uxusR' 


DEFEND ON zo EVENT 


; VAR ro ™ 
THE FOLLOWTNG ‘COMION RRMNTS “ANE tp 


‘1 DORMANT “NOT WAIT Ng To RUN 


"WAXTIM' = -USER- RUNS AT. SA 
“"TBASE' = BASE TIME FOR-C 
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'WATTIM' = THE. LAST TIME THAT. USER. BEGAN. To WAIT 
"LINMUL' = USER LINE MULTIPLIES 
"PLIST' - THE POSITION LIST SPECIFIES THE POSITIONS 

OF THE USERS WHICH ARE .IN toc WORKENG QUEUE | 
‘ULIST' > THE USER LIST INDICATES THE USER NUMBERS 

WHICH CORRESPOND, 0 -¥ ESE, QUEUE. POSITIONS 
'ENDPTR'. = ENDPTR(J) 1S END OF QUEUE J IN PLIST . : 
"NOTIME' - NOTIMECJ) 1S SET TO .2.1F USER JNACTIVE ‘ 
AND USER J WILL SUBSEQUENTLY BE LOGGED OUT 


THE FOLLOWING COMMON. VARIABLES: ARE USED - 
"MXUSRS' = MAX. NO. OF FOREGROUND USERS. . 
‘CURUSR' =. CURRENT. USER,. RUNNING OR SWAPPING 
"QLDUSR' - LAST USER TO. BE RUN, WHEN "SWAP' .NE. 0 
"NEWUSR' ~ NEXT USER TO. BE RUN, WHEN 'SWAP' NE. 0 
"RAYUSR! .- THE USER CURRENTLY: PAYING -FOR, TIME 
"SYSTIM' = TIME SYSTEM WAS: ENIZIALAZED _ 
"BEGTIM' - THE LAST TIME. 'CURMSR’.. 
"QUANTM' = MAXIMUM RUNALENG: Th 


"PAYTIM' = LAST TIME A USER WAR. CHARGED, 
"LEVTIM' = LAST TIME 'C R'. WAS 
"SWAP! = NONZERO REQUESTS: ‘AMERY I 
TNEWUSR! AS: SOON: AS..1T CAN. 

'MAXLVL' = THE MAXLMUM PRIOR ETY. LEVEL CO ae Sli 
"MLNLVL' - THE MINIMUM PRIQRETY. LEVEL. ALLOW 

"FULLVL’. - INIT. LEVEL. FO on ees 
"EMPLVL' ~ INITIAL LEVEL FOR barat cone USE 
‘FULLEN' =. LENGTH. een Pence bg 

'PB' = GUARANTEED € FOR. 


BACKE ROUND 

ris oSrane LeveL CHANGE 

‘LeviNet “4 ote unter EVEL 4S BNCREASED WHEN . 
USER RETURNS TO WORKING FROM INPUT OR OUTPUT WAIT | 
"INACTV' = MAX, TIME LNACTNE BEFORE: LOGOUT 

"HANGUP'’ - MAX. TIME BEFORE UNACT EVE LINE 1S HUNGUP 


COMMON VARIABLES. REFERRED TO..BY. ‘SCHED. BUT 
NOT SET OR CHAMGED. BY. S 

"BKGTIM’ ~ TOTAL TIME. BACKOROUND. MAS RUN 

"SWPSW' ~- NON@“ZERO WHEN SUPERY 1SOR: 1s SWAPPING AND 

~ COMMAND LOADING. 


~ 'PROBN(J)' - NON-ZERO WHEN USER J 1S LOGGED IN 


"ADOPT(J)!' - PROBN(J) ~AND. ADOPT) ay. 18, THEN 
USER J IS, ADOPTED 


SCHED, CALLS. THE: FOLLOWING SUBROUTLNES . oe , a 
INITQ. - INITIALIZES QUEUES. 
HEDUSR. - RETURNS. THE HEAD. OF QUEUE 
AT HIGHEST NON-EMPTY PRIORITY S BOER ORO. 
DELQUE.(J) - DELETES USER J FROM. QUEUES 
ENDQUE, (J) + PLACES USER J AT END OF QUEUE LEVEL(J) 


A aes er ato 


cTss Technical Notes — aaa PAGE 41 


BEGQUE.(J) - PLACES. USER J AT BEG OF. Queue. LEVEL (J) 

1LOG2.(N) = RETURNS INTEGER PART OF LOG TO BASE 2 N 

1. (J) = CONVERTS FORWARD INDEX 'J' TO BACKWARD. 
INDEX FOR REFERRING TO MAD ARRAYS 

INITIM, - INITIALIZE TIME ACCOUNTING 

INTIM, ~ USER 'U' LOGGED IN 

OUTIM. - USER ‘U' LOGGED OUT 

CHARGE.(U,T) - CHARGE USER ‘U' FOR TIME T! 

GETOTL, - RETURNS THE TOTAL TIME SYSTEM HAS RUN” 

DELTIM.(T) = RETURNS DELTA 'T* - THE DIFFERENCE 
BETWEEN 'GETOTL.()* AND TIME 'T' — 
TIME 'T' IS ALSO SET TO GETOTL.(0) 

CURTIM.(0) - RETURNS THE CURRENT TIME SINCE MIDNIGHT 
OF DAY SYSTEM WAS INITIALIZED 

MONSC1. (EVENT, USER, ARG) MONITORS SCHED. — 

MONSC 2. 1S CALLED WHEN. SCHED, CHANGES COMMON 

PLOT1. (EVENT, USER, ARG) PLOTS ‘SYSTEM ON ESL SCOPE 

PLOT2. 1S CALLED WHEN SCHED. CHANGED COMMON 


DDABDDADANDAAAARAADADADA 


EXTERNAL FUNCTION(A, B, C) 
ENTRY TO SCHED. 

“NORMAL MODE IS INTEGER 

R 


R.. SHORTEN LINKAGE, SETUP USER INDEX, CALL MONITORING SUB., 
Ree CALL PLOTTING ROUTINE 
Ro. ASSUME COMMON WILL BE CHANGED, AND DISPATCH ON "EVENT! 


R 

EVENT = A 

USR = B 

LUSER = 1, (USR) 

ARG = C 

EXECUTE MONSC1. (EVENT, USR, ARG) 
EXECUTE PLOT1. (EVENT, USR, ARG) 

MONITR = CHANGE 

STATEMENT LABEL MONITR, RETURN, CHANGE 
TRIO EN TO EVNTCEVENT) 
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Ro. ‘EVENT .E. 0, INITIALIZE SCHEDULING ALGORITHM FOR N USERS 
Ree eres 1 NDE PENDENT coMmGn ‘VARI ais LES 


 EVNTCO) MXUSRS 


= 31 
MAXLVL = 8 
MINLVL = 0 
FULLVL = 3 
EMPLVL = 2 
FULLEN = 6096 
PB = 0 
QNTWAT = 3600 
LEVINC = 0. 
QUANTM = 30 
TBASE = 0 


INACTV = 216000 
HANGUP = 7200 


R 


Ree INIT{ALIZE QUEUES AND TIME ACCOUNT I NG 
EXECUTE INITQ, 
EXECUTE INITIM, 


R.. INITIALIZE TABLES 
THROUGH JLOOP, FOR J = 0, 1, J .G. UMAX 
JUSER = 1.03) © . 
. COPE LINMUL (JUSER) =l1. 


Ree SET BACKGROUND(USER 0) TO RUN 

R.. USER 0 1S ALWAYS IMPLICITLY AT END oF AUENES 
SYSTIM = CURTIM, Mes 

STATUS(I.(0)) = 


R 


SWAP = 1B 


FIRSTS = 18 
BGMAX = 180 
TRANSFER TO CHANGE 
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aes 7 CTS: TachntealWeths 


a | Ro. "EVENT' .E, 1, CLOCK. INTERRUPT 
Pee Psag R.. ASSUME. COMMON. WiLt wor BE CHERSED 
ce EVNT(1) MONITR # RETURN 
ce ICUR = 1, (CCURUSR) 
oe T= GETOTL.O) 
ae gees R.. DO THE FOLLOWING CHECKING EVERY 10 SECONDS 
a R.. CHARGE PAYING USER FOR TIME 
Las R.. MOVE LONG WAITING USERS. UP. TN PRIORITY 
pe R, LOGOUT INACTIVE USERS, HANG UP INACTIVE LINES 
eleueee WHENEVER T .G,. CHECKT 
rea CHECKT = T + 600 
EXECUTE CHARGE. (PAYUSR, DELTIM, cPaYTMD) 
THROUGH KLOOP, FOR K = 1, ‘UMAX 
WHENEVER: K LE. CURUSR, "TRANSFER "70 ‘KLOOP 
KUSER = 1.(K) 
DELT = T - WATT PMC KUSER) 
E WHENEVER SPATS CUSED. ne. f LOR. STATUS( KUSER) o£. 2 
— , - “WONITR = CHANGE } : 
Wee EXECUTE DELQUE. (Kk 
se LEVEL (KUSER) = LEVEL (KUSERD -1 
ee : EXECUTE ENDQU E.¢ Rr 
: WATTIMCKUSER) = 
TIMLEV(KUSER) | = o 
ee END OF CONDITIONAL | 
bh ‘OR WHENEVER PROBN(KUSER) .NE. 0 
a WHENEVER DELT ..G, tNACTV AND, “LINEWOCKUSER) -E. 0 
MONITR = CHANGE | 
NOTIMECKUSER) = 2 
WATTIMCKUSER) = T 
oe 3 END ‘OF CONDI TIONAL 
eee OTHERWISE 
Loe ~. (WHENEVER DELT..G, HANGUP CAND, ADOPT(KUSER) .E. 0 
- MONELTR = CHANGE 
 NOTIMECKUSER) = 4 | 
WATTIM{(KUSER) = T 
END OF CONDITIONAL 
END OF CONDITIONAL 
KLOOP CONT I NUE 
END OF CONDITIONAL | 
Ree MOVE LONG RUNNING 'CURUSR" DOWN IN PRIORITY 
Bsa CURUSR .NE. 0 .AND. T .G. MAXTEM © 
~¢@ AND, NOT, SWAP : ) ai 
MONITR = CHANGE 
EXECUTE DELQUE.(CURUSR) | 
WHENEVER LEVELCICUR) .L.- MAXLVL, 
on LEVELCICUR) = LEVEL (1CUR): oo 
EXECUTE ENDQUE. (CURUSR) 
LEVTIM = T 
TIMLEVCICUR) = 0 
MAXTIM = T * TRUN, (CURUSR, LEVEL(ICUR)) 
END OF CONDITIONAL 
TRANSFER TO DECIDE 


 €VNT(2) WHENEVER USR .NE. 0, TRA 


ee Notes... 


Ree ‘EVENT! Es 2. rt Teed chauaep, STAT 
Re. — DISPATCH ON NEW shawet oer ie dete cs 


TRANSFER TO RETURN 


R 

R. "USR'C'IUSER') WENT ‘DEAD, EVENT. 6. wee wor OCCUR 
STAT (UD EXECUTE DELQUE. (USR) 

STATUSCIUSER?. = 0 

TRANSFER. To ‘DECIDE 


R 
Ro.  ‘USR'C'TUSER') WENT DORMANT. WHILE RUNNING 
R.. OR PUSHED QUIT BUTTON 


STAT(1) EXECUTE DELQUE. (USR) 
STATUS(JUSER) = 1 | 
WHENEVER USR .E. CURUSR, TRANSTE TO DECIDE 
spe EER TO CHANGE 


Res : "USR'C'TUSER' ) To. BEGIN WORKING AFTER 0 WAITING 
Ree - OR “ALARM CLOCK RETURN FROM DORMANT TO. WORKING 
STAT(2) WHENEVER STATUSC(1USER) «GE. & «OR. ‘STATUS( 1USER) -E. 1 
WHENEVER STATUS(IUSER) .NE. 2. 
WHENEVER LEVEL CIUSER) - LEVINC GE. MINLVL, 
LEVELC(IUSER) = LEVELCIUSER) < LEVINC 
LEV = LEVELF. (LENGTH(LUSER)): 
WHENEVER LEV .L, LEVEL (1USER), LEVEL (1USER) = LEV 
 TEMLEV(JUSER) = 0 
END OF CONDITLONAL 
EXECUTE ENDQUE.(USR) 
WATTHMCIUSER) = GETOTL. co) 
STATUSCIUSER) = 2 
TRANSFER TO’ DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 
R 


Ree "USR' C'EUSER') BEGAN. WAITING FOR A COMMAND 
STAT(3) LEV = LEVELF.(LENGTHC(IUSER)) | 
WHENEVER STATUSCIUSER) .£, 2 AOR. “STATUS C1USER) o£. 3 
WHENEVER LEV .G. LEVELCIUSER) 
EXECUTE DELQUE.(USR) 
TRANSFER TO. COMAND: 
END OF CONDITIONAL 
OTHERWISE 


ry 


COMAND LEVELC(IUSER) = LEV 


EXECUTE ENDQUE, (USR) 
TIMLEVCIUSER) = 0 
WATTIM(IUSER) = GETOTL. (0) 
END OF CONDITIONAL 
STATUS(IUSER) = 3 
TRANSFER TO DECIDE 
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R.. 'USR'C'ITUSER') ENTERED INPUT WAIT 
STAT(4) WHENEVER STATUSCIUSER) .E. 2 
EXECUTE DELQUE,. (USR) 
STATUSC(IUSER) = 4 
TRANSFER TO DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 
R 
Ree "USR'C'TUSER') ENTERED OUTPUT WAIT 
STAT(5) WHENEVER STATUSCIUSER) .E. 2 
EXECUTE DELQUE.(USR) 
STATUSCIUSER) = 5 
TRANSFER TO DECIDE 
END OF CONDITIONAL 
TRANSFER TO RETURN 
R 
R.. THE NEXT THREE EVENTS ALWAYS OCCUR IN SEQUENCE 
Ree WHEN CONTROL !S TRANSFERRED FROM ‘OLDUSR' TO ‘NEWUSR' 
Re. AS A RESULT OF 'SWAP' BEING SET NON-ZERO, 
R.. 'OLDUSR' DOES NOT PAY FOR HIS DUMP, UNLESS 
Ree "NEWUSR' IS OF EQUAL OR LOWER PRIORITY. 
R.. 'NEWUSR' ALWAYS PAYS FOR BEING RESTORED EXCEPT 
Ree BACKGROUND NEVER PAYS FOR DUMP OR RESTORE. 


Re. 'EVENT' .E. 3, SAVING OF 'USR'C('IUSER') IS BEGINNING 
Ree EVENT 3 MAY BE CALLEN FOR ANY OF THE FOLLOWING: 
R 1. FREEING UP CORE B BECAUSE 'CURUSR' EXTENDED SIZE 
R 2. FREEING UP CORE A DRUM BUFFERS FOR SWAPPING 
R 3. DUMPING 'OLDUSR' 
R 4, DUMPING OTHER USERS TO MAKE ROOM FOR 'NEWUSR' 
BOOLEAN SWPSW, FIRST3, DMPOLD, SWAP 
EVNT (3) WHENEVER SWPSW 
WHENEVER FIRSTS 
FIRSTS = OB 
EXECUTE CHARGE,.(PAYUSR, DELTIM. (PAYTIM) ) 
WHENEVER LEVELCI.(NEWUSR)) GE. LEVEL(1.(OLDUSR) ) 
1 »AND. OLDUSR .NE. 0 .OR. NEWUSR .E. 0 
PAYUSR = OLDUSR 
OTHERWISE 
PAYUSR = NEWUSR 
END OF CONDITIONAL 


TIMLEV( I, (COLDUSR)) = TIMLEV(CI.COLDUSR)) + DELTIM.(LEVTIM) 


OTHERWISE 
EXECUTE CHRGSW, 
WHENEVER USR .E, OLDUSR 
DMPOLD = 1B 
OR WHENEVER DMPOLD .AND,. USR .NE. OLDUSR 
1 ~AND, NEWUSR .NE, 0 
PAYUSR = NEWUSR 
END OF CONDITIONAL 
END OF CONDITIONAL 
END OF CONDITIONAL 
TRANSFER TO CHANGE 
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Bins ‘EVENT! gEv chs RESTORING oF 'NEWUBR! AS BEGINNING 

EVNT (4) "ERECUTE CHRGSW. 
WHENEVER NEWUSR .E. 0 

PAYUSR = OLDUSR 
OTHERWISE 

PAYUSR = NEWUSR 
END OF CONDITIONAL 
WHENEVER STATUSCI.(OLDUSR)). .E. 2, ‘ 
1 WATT IM(1. COLOUSR)) = GETOTL.(0) ; 
CURUSR = NEWUSR . 
TRANSFER TO CHANGE a” 


R 
R.. ‘EVENT’ .E, 5, ‘NEWUSR' BEGINS RUNNING AFTER RESTORE 
_. EVNT(S5) EXECUTE CHARGE, (PAYUSR, DELT IM. (PAYTIMD) 
. PAYUSR = NEWUSR 

WHENEVER STATUS(I.(NEWUSR)) LE. s STATUS(I. (NEWUSR)) = 2 
BEGTIM = GETOTL. (0) 

LEVTIM = BEGTIM 

MAXTIM = BEGTIM + TRUN. {NEWUSR, LEVELGI, -CNEWUSR) )) 
1 = TIMLEVCS. rpslake ta 

SWAP = UB 

FIRST3 = 1B 

DMPOLD = UB 

TRANSFER TO DECIDE 


EVNT (6) 


EVNT(7) 


EVNT (8) 


EVNT (9) 


EVNT(10) 


EVNT(11) 
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Ro. ‘EVENTS .E.. 6, 'USR'('1USER!): CORE #S OF LENGTH 'ARG' 
R.. JUST BEFORE ENTERING: WAITING COMMAND 
Ree OR LENGTH CHANGED WHILE srisiestoads 
LENGTH(TUSER) = ARG: 
WHENEVER USR .E. CURUSR 
LEV = LEVELF,(LENGTHCIUSER)) 
WHENEVER LEV .G. LEVEL (TUSER), 
1. MAXTIM = BEGT IM + TG (CURUSR, LEV) ~ TIMLEV(IUSER) 
END OF CONDITIONAL | 
TRANSFER TO CHANGE 


R ge 
Re. ‘EVENT’ .E, 7, OPERATOR SET KEYS TO ‘ARG’ 
- KEYS. = ARG 

BACKGR = ARG 

TRANSFER TO DECIDE 


R ; . : 
Ro. ‘EVENT’ .E. 8 "USR'C('IUSER') LOGGED IN PROPERLY 
LINMULCIUSER) = ARG- 

EXECUTE !NTIM. (USR) 

TRANSFER TO CHANGE 


R : 
R.. ‘EVENT' .E. 9, 'USR'("IUSER') LOGGED OUT 

EXECUTE OUTTIM. (USR) 

TRANSFER TO CHANGE 
R 
R.. "EVENT' .£. 10, 1S "NEWUSR’ STILL RUNABLE 

WHENEVER STATUS(1,(NEWUSR)) .E, 2 
1 OR, STATUS(I.(NEWUSR)) .E, 3, TRANSFER TO RETURN 
SWAP = 0B 

TRANSFER TO DECIDE 


R 
Ro. ‘EVENT’ .E. 11, 'USR'('IUSER') DIALED UP COMPUTER 
WATT IMC TUSER) = GETOTL.(0) 
NOTIMECIUSER) = 0 
TRANSFER TO CHANGE 
R 


- DECIDE 


| CHANGE 
“RETURN. 


CTSS Technical Notes PAGE: 48 


R.. COMMON: EXIT FROM SCHED, 

R.. DECIDE IF IT 1S TIME TO RUN A NEW USER 
R 

R 


ee NO DECISION WHILE SWAPPING 
WHENEVER SWAP, TRANSFER TO" MONITR 


R 
Re. CHECK IF BACKGROUND NOT MEETING GUARANTEED PERCENTAGE 
WHENEVER SKGTTM .L, (PB/100.) * GETOTL (0) 
1 AND, CURUSR .NE. 0, BACKGR #1. 

U = HEDUSR, (0) 

WHENEVER BACKGR .NE. 0 OR, KEYS oNE. 0,UF 0 
R ; 


R.. RUN USER 'U' IF 'CURUSR' HAS RUN AS LONG AS 'U* WOULD 
WHENEVER U .NE,. CURUSR .AND, 
1 . (PREMPT. (TRUN, (CU, LEVEL(}. (ud))) -OR, CURUSR .E. 0) 
2 ~OR. STATUSC! .(CURUSR)) .NE. 2 .OR. BACKGR SNE, 0 
MONITFR =. CHANGE. ; 
SWAP = 18 
NEWUSR = U 
OLDUSR = CURUSR 
BACKGR = 0 
END OF CONDITIONAL 


R 
Ro. CALL MONSC2, IF COMMON CHANGED, ELSE JUST RETURN 
TRANSFER TO MONITR 

EXECUTE MONSC2, 

EXECUTE PLOT2, 


FUNCTION RETURN 


” 


“as oe 
i 
Se aeedine s S ay 
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Rae INTERNAL FUNCT IONS 

TRUN R.. "TRUN' - COMPUTES RUN TIME FOR USER 'DU' AT LEVEL ‘DL! 
INTERNAL FUNCTION TRUN, (OU, DL) = 
1 TBASE + LINMULC(T. (0U)) * ‘QUANTM” *# 2).P. DL 


| R 
LEVELF R..  'LEVELF’ - COMPUTE PRIORITY LEVEL BASED ON LENGTH ‘LEN’ 
INTERNAL FUNCT IONCLEN) 
ENTRY TO. LEVELF. 
WHENEVER LEN .GE, FULLEN 
L = FULLVL 
OTHERWISE 7 
L = EMPLVL + 1L0G2. (LEN/ (FULLEN/ (2 .P. (FULLVL-EMPLVL )))) 
END OF CONDITIONAL 
FUNCTION RETURN L 
END OF FUNCTION 


R 
PREMPT R.. "PREMPT' = [S TRUE IF PREMPT ION tS PERMITTED 
Ro. .. BASED. ON TIME PNTERSUPTER MILL RUN "TNTRUN® 
- BOOLEAN. PREMPT, 
INTERNAL FUNCTION PREMPT. CENTRUN) = 
1 INTRUN .L. GETOTL.(0) - BEGTIM 
5 
Ree SUBROUT INE TO CHARGE SWAPPING TIME 
CHRGSW R.. | FOREGROUND. PAYS FOR BACKGROUND SWAP UP TO 3 SECONDS 
INTERNAL FUNCTION 
ENTRY TO CHRG SW. sf 
TDEL = DELTIM., (PAYTIM) 
WHENEVER OLDUSR .E. 0 .AND. TDEL .G, BGMAX 
EXECUTE CHARGE. (PAYUSR, BGMAX) © 
EXECUTE CHARGE.(0, TOEL- BGMAX) 
~ OTHERWISE 
EXECUTE CHARGE. CParuge, TDEL) 
END OF CONDITIONAL 
FUNCTION RETURN 
END OF FUNCTION 
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peep VARIABLES | stapes nae 
VECTOR VALUES” Sonne = = 32561 — 
VECTOR. VALUES UMAX © S20 
, VECTOR VALUES UHAX = 51 


R,.  "MXUSRS" ‘MUST. BE tte. 52 ‘AND’ ewe must ae LE. 10 
‘DIMENSION FAKE(32561) 
DIMENSION DUMMYO(51), STATUS(51),. LENGTH(51),, LeveL (51) : 
DIMENSION TIMLEV(S1) : : 
. AMENSION WATTIMC51), LINMUL(O),. DUMMY 2.(7 3) | 
~ DIMENSION PLIST(73},. ULISTCO), DUMMY 42.0, ENDPTR(LO) 
‘DIMENSION TOTLEV(0) 
“DIMENSION DUMMY6(51), TA1(51), - TAZ({52),.  . TAS51) 
DIMENSION TAK(51),° TUA(51), - TUZ 51), | 03081) 
-DIMENS. FON Te: Ne NOTIN a 51). 
&:, 


DIMENSION LENENO(S1), LENCR(S1), ‘MANUALTSDD , RSPONS(52) 
. DIMENSION FULLSW(5Z) pel 
DIMENSION UDWAIT(51),. ‘RWORDS(51), wiorDs(51), ‘RTIMES(51) 
DIMENSION WTIMES(C51) 
DIMENSION UNITID(CS1), SOMMNDCSL De INTRSWLS), 
-DIMENS TON. ‘ULINEC > T 
DIMENS 10N 


PROGRAM COMMON FAKES ee 
aaa eater BIND AND. CHANGED: ay. i 
oe Fe SCHE 
Hoes PROGRAM COMMON DUMMYO, STATUS, LEMEIH,. LEY 
be PROGRAM COMMON WATTIM, LINMUL, DUM | ea Ty. UL 
ee PROGRAM COMMON DUMMYS, ENDPTR, TOTLEY.... =. | 
a R.. TABLES SET BY LOGIN, UPDATED BY TIME A 
PROGRAM COMMON DUMMY6, TAL, TAZ, TAS, TAB 
PROGRAM COMMON TUl1,  TU2, TUS, Tus, UTIME 
PROGRAM COMMON NOTIME . 
Ree TABLES SET BY LOGIN | 
"PROGRAM COMMON ITIME, PROBN, PROGN 
R,. USER OPTIONS(CHECKED BY CLKINT mr TEORRD) 
PROGRAM COMMON LINENO, LINCR, MANUAL, RSPONS, FULLSW 
R.. TABLES FOR DISK MONITORING : oe 
PROGRAM COMMON UDWAIT, RWORDS, WWORDS, RTIMES, WTIMES © a 
Ry. OTHER USER TABLES : e 
PROGRAM COMMON UNITID, ‘coum, INTRSW, HUNGSW, *' INES 
PROGRAM COMMON OUTPSW, COMCTR, 100, ULINE, “INCT 
PROGRAM. COMMON UCLOCK, UCHARG, eat | TIMIENC, ¢°,0CON © 
_ PROGRAM COMMON ADOPT, OKPROS, | 
| R., COMMON VARIABLES SET AND CHANGED 8Y $CHEDL. ONLY 
bas PROGRAM COMMON MXUSRS, CURUSR, OLOUSR, NEWUSR, PAYUSR | 
r a PROGRAM COMMON SYSTIM, BEGTIM, QUANTM, MAXTIM, TBASE 
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PROGRAM COMMON 
PROGRAM COMMON 
PROGRAM COMMON 
PROGRAM COMMON 


Notes 


PAYTIM, LEVTIM, SWAP, 


FULLVL 
EMPLVL, 
LEVINC, 


FULLEN, 
INACTV, 


Ro. VARIABLES SET BY LOGIN 


PROGRAM COMMON 
Ree 
PROGRAM COMMON 
PROGRAM COMMON 
PROGRAM COMMON 
PROGRAM COMMON 
PROGRAM COMMON 
PROGRAM COMMON 
PROGRAM COMMON 
Ro. USER MACHINE 
R.. 
END OF FUNCTION 


SPROBN, 


OTHER VARIABLES 


USER, 
SWPSW, 
COMT IM, 
CLKTIM, 
DSKLOC, 
BUFULL, 
PBUFF, 


SPROGN 


DATE, 

COMSW, 

USRWAT, 
MXLINE, 
BASEAD, 
DUMMY C 
DUMMY E, 


PB, 
HANGUP 


DATEYR, 
TOTTIM, 
SWPWAT, 
NWORDS, 
WAIT, 


DBUF1, 


CONDITIONS STATUS TABLE 


(NOT REFERRED TO BY MAD PROGRAMS) 


MAXLVL, 
QNTWAT 


TIMNOW, 
BKGTIM, 
COMWAT, 
STOPSW 
DUMMY 8, 


DUMMYG, 


MINLVL 


NUSERS 
SWPTIM 
AUTOND 
READY 


DBUF 2 
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5. . Flow Charts of Main Control and Trap Processors. 


Introduction. © 

This section consists of five. flow charts — of Main . 
Control, the clock and protection trap. processors, ‘and the 
module RSTCPU. These flow diagrams are to’: help provide. a 


temporary bridge between complete lack of fnformatfon about 
these modules and the. assembly listings ene vere: 


Call SCHEDL 
| CEvent 10) 
‘Last chance 


CMPROC 


Is NEWUSR In 
(on next 


“Walting Command" 


Restore NEWUSR 
Call SCHEDL 
(Event 5) 


Figure 5.1 -- Cycle entry of Main Control. 


SS ty 
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1s command 
on disk 


no 


Is user 
= NEWUSR 
no 


Dump USER 
Restore NEWUSR 


Call SCHEDL 
(Event 5) 


ts command 
in core 8B 
no 


Transfer to 
core A command 


yes 


Insure 
Enough Room 
for command 
(FREEUP) 


= NEWUSR 
no 


Dump USER 
Restore tables 
for NEWUSR 


Load command 
file into 
core B 


Reset user 
machine conditions 
and active files, 


Call SCHEDL 
(Event 5) 


Figure 5.2 ~=- Command Processing in Matin Control. 
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a Ls the-user 
Index In the 
7. polltag loop.) 


Machine 
Conditions — 


Ts_ mes 
, Z 


Lunes) #0 


J 


STATUS(1) = 5 


Call SCHEDL = 7 
(Event 2) to “T 
change STATUS |: 
o Working (2)1. 


Return to 
interrupted 
Program via 
Common Exit 


Call SCHEDL 
CEvent 1) 


Figure 5.3 -- The Clock Trap Processor. 
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1s SWAP # 0 


Did user Interrupt? 


Is he expecting 
interrupts? 
yes 


Save current 
Reset ILC for 
Interrupt 


ILC, 


Type: 
"No Action" 


Drop user 


Interrupt level 


Type new level number 


at ILC location 
STOP AT 0000" 


Go to user, 


Figure 5.4 -- Flow dlagram of RSTCPU (Restart user.) 
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Protection 
: ‘Mode 
violation 


ave user 


machine 
conditions 


[0oes user's — 
ILC violate 


| PIck up 
violating 
Instruction 


Pick up word 
at address of 


Transfer to 
user subrout inet 
(in protection 
section.) 


Figure 5.5 <= Tre Protection trap processor. 
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6. The Disk Control Module, 


Introduction. 


As mentioned earlier, there are four distinct uses of 
the disk and drum memories: 1) temporary storage of working 
programs whitch do not fit [Into memory; 2) storage of 
supervisor command programs; 3) storage of user programs and 
data; and 4&) scratch pad storage by user programs. These 
uses have enough In common, however, that a single interface 
program, the Disk Control Module, handles all use of these 
memories. Calls from the supervisor are not distingulshed 
from calls from a user. program. In particular, the 
supervisor does not attempt at any time to use the disk 
except through the disk control module. 


In addition to this disk control program, there Is a 
palr of disk load and dtsk dump programs which are used _ for 
off-line input to and output from the disk memory. These 
routines are not part of the supervisor and in fact do not 
presently operate while the time-sharing system is running. 
The dump routine copies the contents of the disk memory onto 
tape for backup purposes, and processes users' request cards 
to produce printed and punched copies of thelr personal 
files. The load routine coples a tape onto the disk to 
re-iInitialize the time-sharing system, and also processes 
users' request cards to add flles (consisting of punched 
cards) to the disk, 


The Disk Contro}) Routines. 


A complete, though slightly out-of-date, technical 
description of the current disk control module may be found 
In the Computation Center Memo CC-196, July 11, 1962. A new 
disk control module Is currently being designed. 


Loading and Dumping the Disk. 


A complete technical description of the two programs 
LDEDT (disk load editor) and DPEDT (disk dump editor) may be 
found In the Computation Center Memo CC-108, May 9, 1963, 
An operational description Is provided in Memo CC-212. 


Disk Routine Tables. 


The format of the master file dlrectory fs shown fn 
figure 6.1. Figure 6.2 [s the layout of the user. disk 
status table as it appears In the disk routine and as it 
appears on the drum or disk when a user leaves core memory. 
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Chain Word 
Programmer Problem 
Number number 
Address of user 
fille directory. 


two-word 
entries 


etc. 


(The first track of the M.F.D.. ts stored on track 0 of 
Module 1.) 


Figure 6.1 -- Format of Master File Directory 


Pr mary fille name 


Secondary file name 


Pn) ae 
used tracks 


count of tracks used 
track quota 
| Htstorical-not used 


Pointer to current 
track usage table track 


UTABLE 


Current 
track of 
keword \ user's 
entries >file 
directory 
(466 wds.) 


TRCNT 
QUOTA 


FILNR 
UFILTR 


Figure 6.2 -- The Disk Status tahle. total size, 551 words. 
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Location of first 

track usage table track 
Switch--UFD has been 
changed 
eee 
Secondary fite name 


Buffer addresses 


FFDRTR 


TPONLY 


CHNGD 
ACTTBL 


Track to be written next 7-word 


entries Active 


Fite 
Table . 
10 x 7 


a words 
Logical Module Asstgnment 


Historical 


NEFMOD 


ASNMOD 5 words 


not used 


Error Flags 


Amount track quota is 
User fille directory 


UFLGS 
TRKOVR 


SVUFDT 


Figure 6.2 (cont.) The User disk status table. 


CTSS Technical Notes PAGE 60 
7. Description of Entry potnts and Cross Reference Table 


introduction. 


An Invaluable aid in studying the operation of any 
single-module or subroutine within a module [s a thumbnail 
sketch of each of the subroutines which It calls. If such a 
sketch Is available, attention can remain within the module 
being studied; the reader need not have ae detailed 
understanding of how the subroutine works to comprehend. the 
program which calls the subroutine. Also, when looking at 
the thumbnalil sketch of a subroutine to figure out what it 
does, it Is useful to have some idea of which other modules 
also call this subroutine; this allows one to establish the 
"nlace" within the system of the subroutine, in this 
section, then, is listed each entry point of each module, a 
brtef description of what the entry polnt does, and a list 
of all modules of the supervisor which call this. entry 
point. The Information In this section pertains to version 
"1Al" of the time-sharing supervisor. All program sizes are 
given tn octal. 


Module ADP] 
Function: 7750 t/0 adapter module, 
Size: 2340 words, 


Entry Points: 


WRTELY Subroutine to write a line on a 
teletype. 
ROTELY Subroutine to accept characters 


from a teletype. 
callers: CHNE (CETRAP) 


Module: 


Function: 


Stze: 


Entry Poltnts: 


Module: 


Function: 


Size; 


Entry Polnts: 
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AP75 


Handles 7750 buffers. 


447 words. 

WT7750 Write output on 7750. 
callers: ADPI, HIGH 

CHNE 


Hardware routine to drive data channel E 
(7750 and teletypes). Contains 7909 
channel programs. 


363 words. 

CHANL|I Subroutine to [nitltalize 7750 and 
channel E. 
callers: CTRL, MAIN 

WR7750 Subroutine to transmit data to 
7750. 
callers: AP75 

ETRAP Channel E data channel trap entry. 
callers: MAIN, channel 
E data channel trap. 

STMPE Shut down channel E for high-speed 
drum, 
callers: STQPR 

STARTE Restart channel E after ST@PE 


has stopped It. 
callers: ST@R 


Module: 
Function: 
Size: 


Entry Points: 


‘Module: 


Function: 
Size: 


Entry Potnts: 


CLEC 
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Clock trap processor module. 


1377 


STCLOC 


CLKINT 


GETOTL 


ADDTIM 


C@MC 


Subroutine to start up Interval | , 
timer ctock. 


callers: CTRL, MATLN 


Interval timer trap entry. 
callers: MAIN; clock trap. 


Get time system. hes. been running. he 
callers: ‘SCHED Hud, 


Update time used. 


. caltersr CTRL, STOR 


Miscellaneous subroutines. 


146 


ENKEYS _ 


STOPIF 


COMCHK © 


SETUSR 


AC. 
catters: chee, CTRL 


_ Subroutine to enter console keys 


of tnterrupt to CTSS. 
callers: CLec, CTRL, PMTA 


Subroutine to stop [If key 24 Is 
own, 
callers: PMTA, RTRN 


Subroutine to search contend . 
directory for command In logical , 


Subroutine to establish current 
user as a disk user. 

callers: CTRL, LOGA, PiRe SAVC 
STPR 


Modules 


Function: 


‘$tze: . 


Entry Poltnts: 


Module: 


Function: 
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BROOM 


SWEEP 


CeMD 


The command 


372, 


COMDIR 
FALE 
LOGIN 
sites 


START 


Scan adaption system 
callers: cCLec, TCOR, PMTA, RDFX, 
L@GA 


Continue BROOM scan. 
felterss CLC, TCOR, PMTA, ROFX, 


LOGA 


directory. 


Entry to command directory 


-coatrol word. 


caller: camc (COMCHK ) SCHED 


 Divect. entry te FILE entry tn: 


command directory. 
callers: CLEC 


> .pPtreect entry: to LOGIN entry in 
 egemand directory. 
calters: CLC, CTRL, PMTA, STOR 


Direct entry to ENDLOG entry In 
command directory. 
callers: CLeC, CTRL, LOGA 


Divact entry to START entry In 


command directory. 


 salters: . C&pc 


TFILE 


conv 


Direct entry to TFILE enEry In 


command directory. 
callers: CL@C 


Conversion routines. 


Size; 


Entry Points: 


Module: 
Functlton. 
Size: 


Entry Poltnts: 
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2468 


CTIME 
TCTIME 


DTBC 


—BTDC 


oTBC 
BTC 


ROYTIM 


CTRL 


Subroutine to convert time In 60th 
to BCD 1/10th méautes, 
callers: LOGA, LOGB- 


Subroutine to convert time In 60th 
to BCD In .01 hours. 
callers: LOGA, PMTA 


Subroutine to convert: deci to 
binary. 

exllers:  C@MC(SETUSR), L@GA, L@GB, 
PNLN, PMTA 


Subroutine to convert binary. to 
decimal. 
callers: LEGA, PMTA 


Subroutine to. convert octal (BCD) to 
binary. 
caller: @cTc 


Subroutine to coavert binary to 


octal BCD. 


callers: ‘pcCTC, PMTA, STPR, -RTRN 


Subreutine te) ebtain user command 
time used, to be typed with: the 
WREADY™ comment 

callers: “CLOC, “CTRL 


Main control module. 


1160 


CHNC9M 


NEWC9M 


Entry to pick up next program-_ 
Intttated command If any. : 
callers: @CTC, PMTA, SAVC 


Entry to set up. new command 
for user, 
callers: PMTA 


Stze: 


Entry 


Module: 


Points: 
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COLN 


DEAD 


ENDUSR 


ENDCQM 


CYCLE 


CKQUIT 


ILLCQM 


OCER 


2168 


EPRINT 


ALLSAV 


ALLRST 


Entry to restart: system after 
XEC loon, etc. 


callers: FDBG(PANIC), MAIN 


Entry to place current user in 
"DEAD" status. | 
callers: LOGA, “PMTA, SAVC, ST@R 


Entry to set user status and type 
ready. = =—s—s eS 
callers: CTC, PMTA, RTRN 


Entry at end of command - ready 
not typed. 
caller: L@GA, PMTA 


Entry to check for more work to do. 
caller: ‘CLEC, PMTA, RTRN 


Subroutine to find if current. 
user has pushed "Qui" while 
In supervisor. 

caller: PMTA, RTRN 


-. Entry after Tilegal sequence 


of commands. . 
caltter! e@CcTC, SAVC 


On-lfne print subroutine (saves 
channel A). 
catter: CHNE, DSKI, STOR 


Subroutine which saves all basic. 
machine conditions. 
calters: CHNE, DSKI 


Subroutine which restores all 
basic machine conditions, 
callers: CHNE, DSK! 
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Module: DSKI 
Functions . Disk control module 
Size: 11506 


Entry Points: 
eDINIT Inttlalfze disk routtIne. 
caller: MAIN 


OPEN Stgn user on to disk, 
callers: C@MC(SETUSR), CTRL, 
LOGA, MAIN, PMTA, SAVC 


CLOSE Remove user from disk file. 
callers: LQ@GA, L@GB, PMTA 


eASIGN Inttialize writing a new file. 
callers: LGB, PMTA, SAVC, STOR 


eAPEND Add to end of an old disk fille. 
callers: L@GB, PMTA, SAVC 


WRITE Write data with a disk fille. 
callers: L@GB, PMTA, SAVC, ST@R 


FILE Terminate writing of a file. 
callers: ‘L@GB, PMTA, SAVC, ST@R 


eRELRW Open a file for relative 
read/write. 
callers: LGB, PMTA, SAVC 


SEEK Initlalize a disk file for 
reading. 
callers: CTRL, LOGB, PMTA, 
SAVC, STOR 


»READ Read data from a disk file. 
callers: CTRL, L@GB, PMTA, 
SAVC, STO@R 

eENDRD Terminate reading from a disk 

file 

callers: CTRL, LOGB, PMTA, 
SAVC, STOR 

-DLETE To delete a disk fille and its 
tracks. 


callers: PMTA, SAVC 
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~CTEST 


«GTFLG 


~SETDU 


oSTATL 


»FILDR 


»UPDAT 


»DFINE 


RESET 


oFSTAT 


eSETAB 


«RDWAT 


» CHECK 


oSTKER 


» ERASE 


Check If a disk channel Is In 
operation. 
(not used.) 


Pick up error or control flags. 
callers: PMTA 


Set current disk user, 
callers: CTRL, L9GB, MAIN, 
PMTA, SAVC, STOR 


Get location of disk user status 
tables. ; 
callers: MAIN 


Read a track of user file 
directory. 
callers: PMTA 


Update user fille directory 
onto disk. 
callers: PMTA, SAVC 


Define a new logical module 
number, 
(not used, ) 


Reset all filles in active status. 
callers: CTRL, PMTA, SAVC 


Obtatn tnformation about a file. 
callers: CTRL, PMTA 


Set memory switches for A or B. 
callers: CTRL, L@GB, MAIN, PMTA, 
RTRN, SAVC, ST@R 


Read out and reset channel 
walting time. 
callers: CTRL, SAVC, ST@R 


Watt until all disk activity Is 
finished, 
callers: STOR 


Set error return on disk track 
error. 
callers: C@MC(SETUSR), CTRL, 
LO@GA, LGB, MAIN, STOR, RTRN 


Delete a flie from directory, 
but leave its tracks. 
callers: PMTA, STQ@R 
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Module: 
Function: 
Stze: 


Entry points: 


Module: 
Functlon: 
Size: 


Entry Points: 
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~GETDS 


« RENAM 


EDBG 


ec Bae esc aE 


PAGE 68 
Get status of active disk files. 
callers: SAVC 


Change name or mode of a file. 
callers PMTA 


System debugging alds 


764 


PANIC 


ADUMP 


BDUMP 


TRACE 


H1GH 


Entry to take a panic dump of 
both cores. 

callers: Console operator's 
restart: MAIN 


Subroutine to dump memory A. 
caller: CL@C 


Subroutine to dump memory B. 
caller: CL@C 


Subroutine to print out a trace 
of all traps. 
caller: CL@C 


High Speed line adapter 


252 


RDH1tGH 


WRHIGH 


Read high speed line. 


caller: ADPI 


Write high speed line. 
caller: ADPI 
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Module: LOGA, B, C 


Function: Login and logout commands and associated 
subroutines. 
Sizes A 1713 
B 1206 
C 131 
Entry Points: 
LOGIN. TSS login command, 
caller: PMTA 
LOGERR Entry in case of error setting 
up user's file directory. 


callers: C@MC(SETUSR) 


ENDLG. TSS Automatic logout entry. 
caller: C@MDIR 


LOGOUT TSS logout command. 
caller: CPMDIR 


Module: MAIN 


Function: Matn Program 

Size: 2205 

Entries: (MAIN PROGRAM) Initialize system, set up trap 
returns, start system running. 

Called By: System loader 

Module: MTRA 


Function: TSS system statIistics collector. 


Size: 


Entry Polfnts: 


Module: 
Function: 
Size: 


Entry Poltnts: 


Module: 
Functions: 
Stze: 


Entry Points: 
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6 (Dummy not presently used) 


MO@NITR 


EREAD 


@CTC 


Octlk, 


200 


@OCTLK: 


PCTPAT: 


PCTTRA: 


ANLN 


On-line 


420 
CLOCIN 


PRINT 


_ Entry to put away statistics. 


caller: CL@C 


Entry to obtain collected 
statistics. 
callers PMTA 


Octpat, and Octtra commands 


TSS OCTLK command for core B. 
caller: C@MDIR 


TSS OCTPAT command for core 8B, 
caller: C@MDIR 


TSS OCTTRA command for core B. 
callers: CQ@MDIR 


device mantpulators for supervisor 


Read data and time from chronolog 


clock. 
callers: L@GA, MAIN 


Print 72 character line on-line. 
callers: CTRL, LOGA, MAIN, 
PMTA, RTRN, STOR 
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PUNCH Punch a card on-line. 
caller: L@GA 


Module: KLUD (PLOT at Computation Center) 
Function: Channel D 1/@ Adapter. 
Size: 2161 at Center, 7173 at MAC 


Entry Poltnts: 
PLOTS Plot statistics on 7094 scope 
(center), 
caller: CL@C 


DSCOPE Display Information on ESL scope. 
caller: PMTA 


DTRAP Channel D trap entry. 
callers: MAIN, channel D data 
channel trap. 


DDTRAP Direct data trap entry, 
callers: MAIN, direct data trap. 


STMPN Stop data channel D for High 
Speed Drum, 
Caller: ST@R 


STARTD Restart data channel D after 
High Speed Drum. 
caller: ST@R 


Module: PMTA 
Functton: Protection trap processor, 
Size: 5144 


Entry Poltnts:; 
PTRAP Entry on protection mode trap. 
callers: MAIN; Protection mode 
violation. 


Module: 


Size: 


Entry Points: 


Module: 


Stze: 
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BKSERV 


ERROR 


DPRINT 


DERR 


USERER 


RFLX 


2705 
RDFLXA 
ENTLIN 
RSSRB 


RSSWB 


RTRN 


241 


Entry to service background 
(requested by Keys). 
caller: CTRL 


Entry to comment after a disk 
error. (not used) 


Entry to print out a disk error 


on-line. 
caller: MAIN 


Entry to process a disk error, 
caller: MAIN 


To process disk track error for 
user, 
callers: CTRL, RTRN 


Entry for a user to obtain a line 
from common input buffer. 
callers: PMTA 


Entry for supervisor to add a 
ltne to common Input buffer. 
calters: CL#C, PMTA 


Entry to reset all [Input lines 
for this user. 
callers: CLC, CTRL, PMTA, TC@R 


Entry to reset user's output 
lines. 

callers: CL@C, CTRL, LOGA, 
TCOR 


Entry Points: 


Modules: 


Function: 


Stze: 


Entry Points: 


Modules 


Functions: 
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RSTCPU 
CMEXIT 


CMXRTN 


LO@AD.4 


SAVC 
Save, 
624 
XDUMP 


SAVE 


RESUME 
XLPAD 


START 


SAVR 


Entry to return to user program, 
callers: CTRL, L@GA, MAIN, 
PMTA, SAVC 


Entry to return to Interrupt 
program. 

callers: CHNECETRAP), CL@C 
DSKI, PLOT, UTRP 


Cell containing return location. 
callers: EDBGC(TRACE) 


Cell containing IRG, 
callers: EDBG(TRACE) 


restore, resume and start commands, 


This Its the SAVE command entry 
point. 
callers: C@MDIR 


‘Subroutine to save a user. 


(Used by XDUMP and ENDL@G). 
callers: L@GACENDL@G) 


TSS resume command. 
callers: CPMDIR 


TSS restor command. 
caller: C@MDIER 


TSS start command. 
callers: C@MDIR 


Save and restore routine, 


73 


Sizes 


Entry Points: 


Modules: 


Function: 


Sizes 


Entry Points: 


Module: 


Functions: 
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SAVCPU 


RESTOR 


LONGSV: 


LNGRST: 
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Subroutines to save basic user 
machine condittons. 
callers: CLO@C, PMTA 


Subroutine to restore basic user 
machine conditions. 
callers: PMTA, RTRN 


Subroutine to save complete user 
machine conditions. 
callers: STOR 


Subroutine to restore complete user 
machine condittons. 
callers: SAVC, ST@R 


SCDA, B, C, D, E, F, G, H 


Scheduling, time accounting, and monitoring, 
Including all subroutInes. 


1567 
421 
523 
22 
174 


mMmoOoOD > 


SCHEDL 


F 266 
G 73 


H 20 


Entry to notify scheduling algo- 
rithm that something has happened. 
callers: CL@C, CTRL, LOGA, MAIN, 
PMTA, SAVC, ST@R, ADPI 


MONSCD,MONINF Mont toring 


STOR 


caller: PMTA 


Storage allocation algortthm module. 


Size: 


Entry Polnts: 


Module: — 
Functton: 
Stze: 


Entry Polintss 
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DUMP 


UNDUMP 


FREEUP 


TCOR 


5205 


TCOORD 
WRELX 
WRFLXA 


RSSRB, 


TOPOOL 
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Scavoctinn ‘to dump user onto ‘disk. 


callers: CTRL 


Subroutine to restore a user from 
the disk, | ns 
callers: CTRL 


Subroutine to freeup N words of 
memory 6, 
callers: CTRL, PMTA, SAVC 


‘Typewriter coordinator - break processor. 


Subroutine to collect Input char- 
acters Into messages and look for 
break characters. 

catlers: cLec 


Subroutine to wrlte a@ message on a 
typewriter, Follow message with a 
carrlage.. 


: r 
callers: ete.” CTRL, LOGA Lec, 
VE 


PCTC, PMTA, RTRN, STER, S 


Subroutine to write a message on a 
typewriter, No carriage return 


provided. oe 
callers: CLOC, LOGA, PMTA 


Subrove tine to reset a user's 


ry read buffer. 
callers: RFLX. 


Subroutine vo sists an Input 


character Ine the character poo) 
buffer. 
callers: — ADAP(RDTELY), HIGH 


Module: 


Function: 


Size: 


Entry Points: 


Module: 
Function: 
Stze: 


Entry Points: 
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RDLINE Obtatn- an Input Vine from break 
processor. 
caller: CLC 
TST@ 
7750 storage allocator. (MAD) 
254 
TGET Subroutine to obtain a block 
of 7750 storage. 
callers: AP75 
TGIVE - Subroutine to give back 
a block of 7750 storage, 
callers: ADAP(ROTELY), HIGH, AP75 
TRESET Subroutine to discard all of a 
user's present output stored 
In 7750. 
callers: AP75 
UNIT 


Assigns logtcal untt numbers to consoles 


247 


ASNUNI 


US2BS 


Subroutine to assign a logical 


unit number to a physical unit. 
callers: ADAP, HIGH 


Subroutine to look up a physical 
unit number given a logical unit 
number. 
callers: ADPI, AP75 
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BS2US Look up logical untt number given 
physical unfit number. 
callers: ADP!, AP75 


ERSUNI Subroutine to erase loprical unit 
assignment. 
callers: CL@C, LOGA 


Module: UTRP 
Function: Process user traps. 
Size: 4228 


Entry Points: 
ATRAP Process data channel trap 
from channel A, 
callers: MAIN, channel A 
data channel trap. 


BTRAP Process data channel trap 
from channel B. 
callers: MAIN, channel B data 
channel trap. 


STRTRP Process STR in a user's program. 
callers: MAIN, STR trap, 


FLPTRP Process floating point traps 
tn user program, 
callers: MAIN, floating polnt 
trap. 


CTRAPS Subroutine to check for waiting 
traps. 
callers: RTRN 


UPCLOC Subroutine to update core clock 
for current user. 
callers: CLAC 
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